We Write code Once But read it 10 Times: Naming Variables

Names are everywhere in software. We name our variables, our functions, our arguments, classes, and packages. We name our source files and the directories that contain them. We name our jar files ,war files and ear files. We name and name and name. Because we do so much of it, we’d better do it well.

“Be conscious while naming variables, as you are conscious while naming your child.”

Code efficiency depends upon the code algorithm It is true but making good logic without naming variables, class names, and function names properly, then it will become hard for you to maintain code in the future.

According to Alex Dix book HCI chapter 1 “The Human”

Your brain keeps new info in its short-term memory for 7 sec and if you forget to recall it it will discard that info .

and then it will become harder for you to remember what exactly that variable means.

so naming variables is as important as writing code with good logic.

Here are some cool Practical tips by Uncle Bob for conscious naming to enhance code readability.

• Use Intention-Revealing Names
• Avoid Disinformation
• Make Meaningful Distinctions
• Use Pronounceable Names
• Use Searchable Names
• Avoid Encodings
• Member Prefixes
• Avoid Mental Mapping

Use Intention-Revealing Names:

Choosing good names takes time but saves more than it takes.

It is easy to say that names should reveal intent. So take care with your names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you do.

The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.

int d; // elapsed time in days

The name d reveals nothing. It does not evoke a sense of elapsed time nor of days.

Instead, name it like,

int elapsedTimeInDays;
int daysSinceCreation; 
int daysSinceModification; 
int fileAgeInDays;

Avoid Disinformation :

Programmers must avoid leaving false clues that obscure the meaning of code.

That's what I'm talking about.

1. Use a list when it is stored in a list.

Do not refer to a grouping of accounts as an accountList unless it’s a List. The word list means something specific to programmers. If the container holding the accounts is not a List, it may lead to false conclusions.

So accountGroup or bunchOfAccounts or just plain accounts would be better.

2. Similar shapes.

Beware of using names that vary in small ways.

//How long does it take to spot the subtle difference between
int XYZControllerForEfficientHandlingOfStrings; 
int XYZControllerForEfficientStorageOfStrings;

3. Spelling similar concepts similarly is information.

4. Using inconsistent spellings is dis-information.

5. Use of lowercase

A truly awful example of disinformative names would be the use of lower-case L or uppercase O as variable names, especially in combination. The problem, of course, is that they look almost entirely like the constants one and zero, respectively.

int a = l;
    if ( O == l )
        a=O1; 
    else
        l=01;

Make Meaningful Distinctions

If names must be different, then they should also mean something different.

Programmers create problems for themselves when they write code solely to satisfy a compiler or interpreter.

Number-series naming (a1, a2, .. aN) is the opposite of intentional naming. Such names are not disinformative — they are noninformative; they provide no clue to the author’s intention.

public static void copyChars(char a1[], char a2[]) {
        for (int i = 0; i < a1.length; i++) {
            a2[i] = a1[i];
        }
    }

This function reads much better when source and destination are used for the argument names.

• Noise words are another meaningless distinction. Imagine that you have a Product class. If you have another called ProductInfo or ProductData, Info and Data are indistinct noise words like a, an, and the.
• Noise words are redundant. The word variable should never appear in a variable name. The word table should never appear in a table name.

Use Pronounceable Names

If you can’t pronounce it, you can’t discuss it without sounding like an idiot.

A company I know has genymdhms (generation date, year, month, day, hour, minute, and second).

we were tolerating poor naming. New developers had to have the variables explained to them, and then they spoke about it in silly made-up words instead of using proper English terms.

Compare this

class DtaRcrd102 {

    private Date genymdhms;
    private Date modymdhms;
    private final String pszqint = "102";
}

to

class Customer {

    private Date generationTimestamp;
    private Date modificationTimestamp;
    private final String recordId = "102";
}

Use Searchable Names

Single-letter names and numeric constants have a particular problem in that they are not easy to locate across a body of text.

Avoid Encodings

It is an unnecessary mental burden when trying to solve a problem.

Encoding type or scope information into names simply adds an extra burden of deciphering. It hardly seems reasonable to require each new employee to learn yet another encoding

Member Prefixes

You also don’t need to prefix member variables with m_ anymore. Your classes and functions should be small enough that you don’t need them.

public class Part {
    private String m_dsc; 
} 

//instead 

public class Part {
    String description;
    void setDescription(String description) {
    this.description = description; 
    }
}

Avoid Mental Mapping

Readers shouldn’t have to mentally translate your names into other names they already know.

Reference Clean Code by Robert C martin

Yet, the true efficiency of your code is unlocked not only through elegant algorithms but also through the clarity bestowed by thoughtful and intentional naming.

Coding is not just about solving problems; it’s about telling a story to both the machine and the humans who follow in your footsteps.

Happy coding, and may your variable names be ever expressive, your functions purposeful, and your classes tell a story of logic and intention.

Tayyba Adien