The Art of Naming (Part 2): Practical Rules for Cleaner, Smarter Code

Developers collaborate better with clear and meaningful variable names

🧹 Part 2 of the “Clean Code Chronicles” — continuing our deep dive into how the names we choose shape the clarity, readability, and long-term maintainability of our code.

Most of the principles and advice in this blog are inspired by Robert C. Martin’s Clean Code and his lectures. My goal is to summarise, modernise, and personalise these lessons so they become practical guidelines I can return to in my future work.

Good programmers write code that humans can understand — Martin Fowler

In the blog Art of Naming (Part 1), we explored how to choose names that reveal intent and avoid confusion.

In this part, we shift from philosophy to practice by looking at concrete rules that help us write cleaner, smarter code every day.

Avoid Encodings and Hungarian Notation

If your variable names look like str_name, arr_accounts, or b_is_valid, you’re not being more precise but you’re adding noise.

Modern tools already tell us the type of a variable with a single hover or shortcut. Encoding types inside names is a leftover habit from an era when editors were primitive. Today, it only makes your code harder to read.

Why Type Encoding Hurts More Than It Helps?

Your goal when naming things is clarity — what this value means or represents, not how it’s stored.

Encodings like str_user_name, i_count, b_flag, arr_items force the reader to parse extra clutter before they can understand what the variable is even about.

Even worse: if a variable’s type changes (which happens often during refactoring), the name becomes inaccurate and therefore misleading.

Compare:

❌ i_count
✔️ item_count

❌ str_message
✔️ message_text or just message

The meaningful name is always the clearer one.

Hungarian Notation: Time to Let It Go

Hungarian notation was popular when compilers and editors lacked sophistication. Its intent was good, make type obvious but today it:

• Slows down reading
• Adds cognitive load
• Breaks when types evolve
• Hides the actual purpose of the value

In modern development, it’s considered harmful because it focuses on mechanics instead of meaning.

Good naming communicates intent, not internal representation.

Better Examples

Prefer:

• user_name over str_user_name
• balance over f_balance
• is_active over b_is_active
• file_list over lst_files

Names should say what something is, not how it is typed.

💡 Takeaways

1️⃣ Skip type prefixes and suffixes — trust your IDE, not your variable names.

2️⃣ Your names should survive refactoring without becoming incorrect.

3️⃣ Choose names that reflect meaning: invoice_total, is_approved, message_text.

Meaning over mechanics always.

Parts of Speech in Names

Choosing the right kind of words for your code makes it instantly more readable. Good naming follows the same rules as clear writing: nouns for things, verbs for actions, and adjectives for states.

Parts of Speech in Names

Classes & Variables → Use Nouns

Classes and variables represent things, so noun-based names make them easy to understand.

Examples:

• user_account
• transaction_list
• message_parser
• email_address

👉 Avoid verbs. Name things for what they are, not what they do.

Boolean Variables → Use Predicate Phrases

Booleans answer a yes/no question. Make that question obvious. Start with is, has, can, should, or similar.

Examples:

• is_active
• has_permission
• is_enabled
• can_send_message

👉 These names instantly tell the reader what true or false means.

Methods & Functions → Use Verbs

Functions and methods should sound like actions, since they do things or perform calculations.

Examples:

• send_email()
• calculate_total()
• find_user()
• update_settings()

👉 Start with a verb describing exactly what the function does.

Getters and Setters → Verb Phrases

Accessor methods speak in a predictable, readable pattern.

Get Darshna Rekha’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Examples:

• get_first_name()
• set_price()
• retrieve_transactions()

👉 Consistency makes APIs easier to navigate.

Enums → Use Descriptive States

Enum values represent conditions or categories, so choose adjective-like or descriptive nouns.

Examples:

• Status.ACTIVE
• Status.INACTIVE
• Theme.DARK
• AccountType.PREMIUM

👉 Enum names should be instantly recognisable as a state, not an action.

The Scope Length Rule

Not every name in your code needs to be poetic. Some deserve full clarity; others just need to get out of the way.

The Scope Length Rule helps you strike that balance by matching name length to how far the name travels in your code.

Short Scope → Short Name

If a name is used in a very small scope, like inside a small loop or a tiny function, short names are perfectly fine and often preferred.

If a name lives for only a few lines, inside a small loop, a tiny function, or a quick transformation, short names are not just acceptable, they’re ideal.

for i in range(10):
    # 'i' is perfectly fine here — small scope, obvious meaning

Nobody benefits from renaming i to loopCounterIndexValue.

Short scope = low cognitive load.

Long Scope → Descriptive Name

When a variable or function is used across a larger scope, spanning several lines, multiple logic blocks, or even an entire module, clarity becomes more important than brevity.

total_invoice_amount = 0

for invoice in invoices:
    total_invoice_amount += invoice.amount

A name like total wouldn't cut it here. The broader the reach, the more specific the name should be.

Applying This to Functions & Classes

• Public or frequently used functions benefit from short, sharp names: parse(), render(), sync()
• Specific or complex functions should be explicit: generate_monthly_financial_report() (Nobody wants to guess what generateReport() actually does.)
• Classes follow the same rule — widely used ones stay crisp, specialised ones stay explicit.

💡Takeaways

1️⃣ Ask yourself: “How far from the definition will someone see this name and need to remember what it means?”

2️⃣ For wide scope: Be descriptive.

3️⃣ For tiny scope: Keep it short.

4️⃣ Use meaning, not length, as the deciding factor.

Avoid Noise Words

Noise words are vague, filler terms like data, info, object, item, manager, or handler — words that sound technical but reveal almost nothing about what the code actually does.

They make names longer without making them clearer.

user_data_object
account_info_manager
temp_list_data

All of these look descriptive at first glance … but tell you zero about what they actually represent.

Why Noise Words Hurt Your Code

Noise words:

• Slow readers down — you have to dig into surrounding code to understand what’s going on.
• Create false confidence — people think they understand the name, but the specifics are missing.
• Age poorly — as functionality evolves, the generic word stays, creating misleading names.

A name like manager or handler could mean anything: does it validate? schedule? clean up? store? orchestrate? send? retry? Something else?

How to Improve

Replace vague, generic noise words with specific, intention-revealing names that describe the role or content.

Instead of vague:

data
info
list
object
manager
item

Use specific domain terms:

customer_records
transaction_history
price_list
payment_processor
session_store
email_scheduler
order
invoice
product

Clarity comes from choosing words that anchor meaning, not words that could describe anything in the universe.

💡 Takeaways

1️⃣ If a word could apply to almost any variable or class, it’s probably noise.

2️⃣ Remove or replace noise words with precise, domain-specific meanings.

3️⃣ Ask: “Does this word actually explain something, or is it just padding?”

Closing Thoughts

Naming well can feel slow and uncomfortable when you’re just starting out. It forces you to pause, think, and sometimes rewrite what felt “good enough.” But that extra care pays off massively.

Clear names don’t just make your code prettier; they make it easier to read, easier to change, and harder to break. Over time, those small choices compound into cleaner systems and calmer developers.

Remember the Boy Scout Rule — Leave the codebase a little better with each change

Think of naming as a daily practice rather than a rulebook. You don’t have to fix everything at once.

Apply the Scout Rule: leave every piece of code just a little better than you found it.

Rename a confusing variable. Replace a misleading method name. Remove a noise term. These tiny improvements reshape a codebase far more than a once-a-year refactor ever will.

Clean names aren’t about perfection, they’re about respect. Respect for your teammates, for your future self, and for the craft of programming.

🧱 In the next part of the Clean Code Chronicles, we’ll go beyond names and explore how to write functions that actually do one thing — and do it well.