The Real Problem With Naming
We've all been there: staring at a blank line, trying to come up with a name for a variable, function, or class. It feels like the hardest part of coding, and sometimes it is. But naming isn't about creativity or finding the perfect word. It's about clear communication. When you name something well, the code reads like a story. When you name it poorly, you force the next developer (or yourself in six months) to decode your intentions.
Start With the Why
Before you write a single name, ask yourself: what does this thing do? Not what it is, but what it does. For functions, that's easy: the name should be a verb phrase. For variables, think about the role the value plays, not the type.
# Bad
items = [1, 2, 3]
def process(data):
total = 0
for d in data:
total += d
return total
# Good
prices = [19.99, 5.49, 3.00]
def calculate_total(prices):
total = 0
for price in prices:
total += price
return total
The second version tells you what the data means and what the function accomplishes. You can read it without tracing through the logic.
Use Intent-Revealing Names
Names should answer questions, not raise them. Avoid generic terms like data, info, temp, or thing. They don't reveal anything. Instead, be specific about the domain.
// Bad
const d = new Date();
const t = d.getTime();
// Good
const currentTime = new Date();
const timestamp = currentTime.getTime();
Even better, if you're working in a specific domain, use its vocabulary. If you're building an e-commerce app, use cart, checkout, invoice. If you're doing image processing, use pixel, canvas, filter. The domain language is your friend.
Keep It Short, But Not Too Short
Short names are great for local variables that are used immediately. But they're terrible for things that live across many lines or are passed around. A good rule of thumb: the larger the scope, the longer the name.
// Bad: too short for a field
private int n;
// Good: clear and descriptive
private int numberOfRetries;
But don't go overboard. numberOfItemsInTheShoppingCart is a mouthful. cartItemCount is perfect. Aim for 2-3 words that capture the essence.
Consistency Is King
Once you pick a naming convention, stick to it. If you use getUser in one place, don't use fetchUser in another. If you use isReady for booleans, don't switch to ready somewhere else. Consistency reduces cognitive load. The reader doesn't have to remember exceptions.
For booleans, prefix with is, has, can, or should. For functions that return a value, use verbs like get, calculate, find. For functions that perform an action, use set, save, delete, send.
# Consistent boolean naming
is_active = True
has_permission = False
can_edit = True
Avoid Abbreviations and Acronyms
Unless it's a widely accepted standard like HTML or API, avoid abbreviating. usr instead of user saves two characters but costs clarity. Acronyms like TMP or CNT are even worse. Write it out. Your editor has autocomplete.
When You Can't Think of a Name
If you're stuck, it's often a sign that the code is doing too much. A function that's hard to name might be doing two things. Split it. A variable that's hard to name might be storing something unclear. Rethink the logic.
Another trick: write a comment describing what the thing does, then turn that comment into a name. For example, "this list contains all the IDs of users who have unread notifications" becomes unreadNotificationUserIds. That's a name with a story.
The Hardest Names: Booleans and Functions
Booleans are tricky because they represent a state. Use positive, clear predicates. Instead of notFinished, use isComplete. Instead of noErrors, use hasErrors. Positive names are easier to reason about.
For functions, the name should describe the result, not the implementation. getUser is better than loadUserFromDatabase because the caller doesn't care where it comes from. But if the function has side effects, make that obvious: saveUser or deleteUser are clear.
Refactor Names as You Go
Naming is not a one-time decision. As your code evolves, names should evolve too. If you realize a variable is misnamed, change it. Don't feel bad about renaming things. It's part of the craft. Most IDEs make renaming easy and safe.
Final Thoughts
Naming is about empathy for the reader. You're writing code for humans first, machines second. A good name saves minutes of debugging and hours of confusion. It's not about being clever; it's about being clear. Next time you're stuck, remember: if you can't name it, you probably don't understand it. And that's the name of the game.
