Naming Things Without Pain

The Real Problem With Naming

We've all been there. You write a function, pause, and stare at the cursor for two minutes trying to decide between getUserData, fetchUser, or loadUser. Naming is hard because names carry intent, and intent is fuzzy. But the pain isn't inevitable. It's a symptom of unclear design or overthinking. Here's how I approach naming in my daily work, without the agony.

Start With the Why, Not the What

Before naming, ask: what is this thing for? A good name describes behavior, not implementation. getUser tells me what it returns. getUserFromApi tells me where it comes from, which is an implementation detail. If I later switch from API to cache, the name lies. Prefer getUser and let the caller not care about the source.

For booleans, use is, has, can, or should. isActive, hasPermission, canEdit. Avoid negatives like notDisabled because they double the cognitive load. isEnabled is simpler than isNotDisabled.

Use the Right Level of Abstraction

Naming pain often comes from mixing levels. If you have a saveUser function that also validates and sends an email, the name is too narrow. Rename it to registerUser or split it. Names should match the scope of what the code does. If you can't find a name that fits, your function probably does too much.

Consistency Beats Creativity

Pick a convention and stick to it. If your codebase uses get for simple getters, don't name a function retrieve. If you use create for object creation, don't use make. Consistency reduces surprise. When I see getUser in one file, I expect getOrder in another, not fetchOrder.

For variables, be consistent with units and formats. timeoutMs and timeoutSeconds are clearer than timeout and delay. If you have a userList, don't call another usersArray. Choose one plural form.

The Two-Second Rule

If you have to think about a name for more than a few seconds, you're probably missing a concept. Step back and ask: is there a term from the domain that fits? For example, instead of itemsThatAreOverdue, call it overdueItems. Instead of checkIfUserCanAccess, call it canUserAccess. Domain language is often shorter and clearer.

Refactor Names Without Guilt

Naming is not a one-time decision. It's okay to rename later when you understand the code better. In fact, that's a sign of growth. I rename constantly during code review. If a colleague suggests a better name, I take it. It's not a criticism of my intelligence, it's a shared effort to make the code clearer.

Practical Heuristics I Use

• Functions: verb + noun. saveReport, sendNotification. Avoid doStuff or handleClick unless it's a callback.
• Classes: noun. User, OrderProcessor, PaymentService. Avoid verbs like Manage unless it's a manager pattern.
• Variables: nouns or adjectives. count, isReady, totalPrice. Avoid data, info, temp unless truly temporary.
• Constants: uppercase with underscores. MAX_RETRIES, DEFAULT_TIMEOUT.
• Booleans: ask a yes/no question. isLoaded, hasError, canSend.

When You're Stuck: Fake It

If you can't find a name, write a comment describing what the function does, then extract the main verb and noun. For example, comment says "this function checks if the user has enough balance to purchase an item". Name: canUserPurchase. If that's too long, userCanPurchase works. If it's still awkward, your function is probably doing too much.

A Simple Process for Naming

1. Write the code first, even with a placeholder name like foo. Get the logic right.
2. After it works, read it and ask: what does this do? Write a one-line answer.
3. Turn that answer into a name. Use the heuristics above.
4. If the name is longer than 3-4 words, consider splitting the function.

This process removes the pressure of naming upfront. You name after you understand, not before.

Final Thoughts

Naming is a skill, not a talent. The more you practice, the faster it gets. I still struggle with names, but now I have a toolkit. I ask why, I stay consistent, and I rename freely. The pain is mostly gone because I stopped trying to find the perfect name on the first try. Instead, I find a good enough name, and I improve it when the code tells me more.

Remember: a name is a contract. It should communicate intent clearly, not impress with cleverness. When in doubt, choose the boring, obvious name. Your future self and your teammates will thank you.