Clean Code: Chapter 2 Notes

Names should reveal intent, there is no revelation in naming an integer d, intending it stands for days. Instead, you should use the following names:

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

Don't postfix the word 'list' to the name 'accounts' unless it's actually a list. This is because the reader will assume the data type of accountsList is indeed a list, instead choose a name like accountsGroup.

While it is possible to name by being disinformative, it is also possible to name being non informative. Consider:

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

What on earth does a[1] and a[2] even stand for? We are better off using names like source and destination (due to the function's intent of copying the array).

Furthermore, noise words are redundant. We should never use the word variable when naming a variable, or table when naming a table.

This is quite straightforward. Do not use a name like genymdhms to refer to generation date, year, month, day, hour, minute, and second. Instead use generationTimeStamp.

In modern IDE's, it is still quite difficult to search for single-lettered variables. The writer states a personal preference of using single-letter names only as local variables and inside short methods. The following principle is given:

The length of a name should correspond to the size of its scope

Don't prefix variables with letters like m_ as was done in the past. Do not type encode as well, an example of this is: PhoneNumber phoneString; we can see the reader being misled into thinking the phone number is a String.

Clarity is king, don't use a name for a variable that only you know what it stands for. For example: using the letter r as the lower-cased version of the url with the host and scheme removed. That's being smart, not professional.

Methods should have verb or verb phrase names.

Do not use names that are only understandable to people whom you share jokes etc with. Furthermore, do not use colloquialism and slang in names.

• Example: HandGrenade instead of DeleteItems
• Example: whack() instead of kill()

If you have multiple choices for naming a concept, use one and stick with it. For instance if your options are fetch, get and retrieve, use one and stick with it throughout.

Where possible use solution domain names, as the people that are going to be reading the code are programmers. Therefore, do not shy away from using CS terms, algorithm names, math names and so forth.

However when it is not possible to use solution domain names (in other words, when there is no "programmer-eese" then use the name from the problem domain. The other programmers can ask the domain expert for clarification. If the code is more to do with the problem domain concepts, then the names should be drawn from them.

Enclose names with well-named classes, functions, or namespaces. When all else fails, then prefix with something that provides more context.

Shorter names are better than longer ones, generally. This is so long as the context and intent is clear. Don't add redundant or irrelevant additions to the name in the for the sake of 'context'.