Introduction
day— What kind of day is it?status— The status of what?user— Which user?
In one of the systems I maintained in the past, I came across code filled with extremely generic variable names like day, status, and user.
It was painful to read and understand what each variable actually represented.
That experience made me wonder:
How can we name things in a way that makes sense not only to others, but also to our future selves?
So I decided to dig into the fundamentals of naming — and summarize what I found.
While the examples below use Python, most of these principles apply to any programming language.
Follow a Consistent Naming Rule
You can use any naming style, but what really matters is consistency within the project.
Here are some common conventions:
Case Styles
Pick one and stick with it.
| Style | Example | Common Usage |
|---|---|---|
| snake_case | user_name |
Python variables, functions |
| camelCase | userName |
JavaScript variables |
| PascalCase | UserProfile |
Class names |
Use Verbs and Nouns Properly
Match the word type to what you're naming.
| Type | Naming pattern | Example |
|---|---|---|
| Function / Method | verb + object |
send_email, calculate_total
|
| Variable / Class | noun |
user, payment_service
|
Prefixes and Suffixes
Use consistent patterns for similar kinds of behavior.
| Type | Prefix | Example |
|---|---|---|
| Getter | get_ |
get_user, get_order
|
| Converter | to_ |
to_json, to_dict
|
| Test function | test_ |
test_user_login |
Share and Automate Your Naming Rules
- Document your naming conventions and share them with your team.
- Use linters like flake8, pylint, or ESLint to enforce consistency automatically.
✅ This keeps your codebase coherent and reduces review fatigue.
Avoid Names That Are Too Short
Avoid Single Words That Lack Context
email # ❌ What is this? An address? A message?
email_address # ✅ Clearer
email_message # ✅ Clearer
Be Careful with Overly Generic Words
Words like data, result, or status are too vague.
Also, avoid using temporary placeholders like tmp or temp.
pending_user # ✅ A user waiting for approval
temp_user # ❌ “Temporary” in what sense?
Avoid One- or Two-Letter Names
Use single letters only when there’s a clear, conventional reason —
for example, loop counters or coordinate axes.
for i in range(10): # ✅ OK, conventional for loops
...
x, y = 10, 20 # ✅ OK for coordinates
Avoid Abbreviations
Abbreviations make search and readability harder.
copy_data # ✅
cpy_data # ❌
Use only well-known abbreviations such as HTML, URL, DB, or ID.
Omit Unnecessary Information
Don’t Include Class Names in Attributes
Keep names concise but meaningful.
class Cat:
def __init__(self, weight):
self.weight = weight # ✅ Don't name it catweight
Don’t Add Numbers to Differentiate Variables
payment1 = ...
payment2 = ...
payment3 = ...
Instead, use a list, dictionary, or more descriptive names.
Don’t Include Data Types in Names
Usually, the data type is obvious or irrelevant.
name # ✅
name_str # ❌
Make Your Names More Expressive
Use is / has for Boolean Variables or Functions
This makes intent immediately clear.
is_valid_email = True
def has_permission(user: User) -> bool:
...
Avoid Negative Names
Negative forms can create confusing double negatives.
if not is_valid: # ✅ Easy to read
if is_not_valid: # ❌ Harder to process
Include Units in Names
This avoids ambiguity about measurement.
weight_kg = 5.2
length_m = 3.0
Use Plural Names for Collections
user = "Alice" # ✅ Single item
users = ["Alice", "Bob"] # ✅ Collection
Watch Out for These Common Pitfalls
Don’t Override Built-in Names
Avoid using names like list, id, sum, or type.
list = [1, 2, 3] # ❌
my_list = [1, 2, 3] # ✅
Think Ahead — Future Changes Matter
- Don’t embed implementation details or formats in names.
-
read_csv()→ If you later support JSON,load_data()is more flexible.
-
- Avoid naming variables after data structures.
-
user_list→ It might later become asetor adict.
-
Conclusion
When I revisited the topic of naming, I realized there’s much more to consider than I thought.
Even names that make sense today can become meaningless months later.
That’s why I try to keep these principles in mind —
to write code that’s not only clear to others, but also to future me.
💬 How about you?
- What naming conventions or rules do you follow in your projects?
- Are there any particular pitfalls or lessons you've learned when it comes to naming?
- What’s the worst (or funniest) variable name you’ve seen?
Top comments (1)
Thanks 💯