Getting Good Names Out of Claude Code
Claude picks safe, generic names by default. Here's how to push it toward names that actually communicate intent.
Naming is one of the hardest parts of programming. Claude makes it easier but has specific failure modes — safe, generic names that technically work but don't communicate anything.
The default naming problem
Claude defaults to names that are conventionally correct but semantically thin. A function that checks if a user's subscription is expired becomes checkSubscription() instead of isSubscriptionExpired(). A list of users with unpaid invoices becomes users instead of usersWithUnpaidInvoices.
The safe names pass review. They also make the code harder to read six months later when context is gone.
Ask Claude to name things explicitly
Adding "use names that describe what the function does, not just what it operates on" to prompts changes the output. Or more directly: "This function checks if a user's subscription has expired. What should it be called?" and then evaluate the options before writing the code.
The questions that produce better names
- "What does this return — a boolean, an object, an ID?" (return type guides naming)
- "What's the caller doing with this?" (use case informs the name)
- "What would make this name wrong?" (constraints sharpen it)
A function that returns true when an account is locked for too many failed attempts: isAccountLocked() is fine, isLockedDueToFailedAttempts() is more precise, hasExceededLoginAttemptLimit() communicates the reason. Which level of specificity is right depends on how many callers need to understand the distinction.
Variable names: context over convention
Claude names variables after their types: user, order, response. These are fine at declaration but ambiguous when there are multiple users or orders in scope. Add context: "Name variables to reflect what they represent in this specific function, not just their type."
pendingOrder, completedOrder, originalUser, updatedUser — these names carry information that order1, order2, user1, user2 don't.
When to rename after the fact
If I find myself writing a comment to explain what a variable or function does, that's usually a sign the name should be better. The comment is compensating for an unclear name. Fix the name, delete the comment.
Claude can help: "Here's a function with this name. Can you suggest a better name that would make this comment unnecessary?"