What kind of day is this ‘day’? — Naming Tips That Won’t Confuse Your Readers

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 a set or a dict.

---

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?

Comments

[Aaron Rose]

Thanks 💯

[Priyanshu Buley]

I try to stick with clear, consistent, and readable names — camelCase for functions, PascalCase for components, and meaningful verbs/nouns.