terminal

codeando_simple

terminal

menu

terminal

search_module

guest@codeandosimple: ~/system/search $ grep -r "" .

Press [ENTER] to execute search

Status

Engine: Ready

Database: Online

Index: V2.1.0_LATEST

bash -- cat clean-code-naming.md
guest@codeandosimple: ~/blog/clean-code $ cat naming-stories.md

NAMES THAT TELL STORIES_

// "The name of a variable, function, or class, should answer all the big questions." - Robert C. Martin

Choosing names is the most frequent task in programming. We name variables, functions, arguments, classes, and packages. We do it so often that we sometimes forget how critical it is for our code's survival.

A good name should reveal intent. If a name requires a comment to explain what it does, then the name has failed.

# 1. Use Intention-Revealing Names

The name should tell us why it exists, what it does, and how it is used. If we have to look up the definition to understand it, something is wrong.

Example:

// BAD

$d; // elapsed time in days

// GOOD

$daysSinceCreation;

# 2. Avoid Misinformation

Avoid words whose meaning drifts from the original intent. Don't name something accountList if it's not actually a List structure. Simply use accounts.

# 3. Make Meaningful Distinctions

If you have two variables with almost identical names like UserInfo and UserData, how does the programmer know which one to use? They are noise words that add no real information.

The same applies to ProductObject or ProductData. If Product is already an object, why add the word "Object"? Don't bring noise, bring clarity.

# 4. Avoid Encodings (Hungarian Notation)

In the past, programmers added the data type to the name (e.g., sName for string, iAge for integer). Nowadays, with modern IDEs and typed languages, this is **unnecessary noise**.

Also avoid class member prefixes like m_name. Your classes should be small enough that you don't need them.

# 5. One Word per Concept

Pick one word for each abstract concept and stick with it. It's confusing to have fetch in one class, retrieve in another, and get in a third for the same operation. Decide which one to use and be consistent throughout the project.

# 6. Meaningful vs Redundant Context

Don't add gratuitous context. If you have a class named User, don't name its field userName, just call it name. When using it, you'll see $user->name, which is perfectly clear.

Note: Shorter names are better than longer ones, as long as they are clear within their context.

A Real Example: Evolution

// LEVEL 1: Cryptographic Code (Bad)

function get_it($l) {
    $res = [];
    foreach($l as $x) {
        if($x[0] == 4) $res[] = $x;
    }
    return $res;
}

What is $l? Why are we comparing with 4? What does $res return?

// LEVEL 2: Code that Tells a Story (Clean)

function getFlaggedCells($gameBoard) {
    $flaggedCells = [];
    foreach($gameBoard as $cell) {
        if($cell->isFlagged()) $flaggedCells[] = $cell;
    }
    return $flaggedCells;
}

Now we know we are working with a game board and looking for flagged cells.

record_voice_over Pronounceable Names

If you can't discuss it in a meeting without sounding like a robot spitting out acronyms, change the name.

search Searchable Names

Single-letter variables (like $e) are impossible to find in a large project.

category Classes = Nouns

Classes should be nouns or noun phrases (Customer, WikiPage, Account).

settings Methods = Verbs

Functions should have verb or verb phrase names (postPayment, deletePage, save).

Conclusion

Choosing good names takes time, but saves much more time in the long run. Your code should read like a well-written story. When names tell stories, the team communicates better, and maintenance stops being a nightmare.

Today's Mission

// Open your current project, find a variable with a generic name ($data, $obj, $temp), and change it to a name that tells its story.