Updated: 2025-08-12 Tue 18:29

# Clean Code: Chapter 2 Notes

books notes

## Table of Contents

- Chapter 2: Meaningful Names
  - Use intention revealing names:
  - Avoid disinformation
  - Make Meaningful Distinctions
  - Use Pronouncable Names
  - Use Searchable Names
  - Avoid Encodings
  - Avoid Mental Mappings
  - Class Names
  - Method Names
  - Don't be cute/Don't use puns
  - Pick one word per concept
  - Solution Domain Names and Problem Domain Names
  - Add Meaningful Context
  - Don't add gratuitous context

Link to Chapter 1 Link to Chapter 3

## Chapter 2: Meaningful Names

### Use intention revealing names:

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;

### Avoid disinformation

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`.

### Make Meaningful Distinctions

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.

### Use Pronouncable Names

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`.

### Use Searchable Names

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

### Avoid Encodings

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.

### Avoid Mental Mappings

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.

### Class Names

> Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb

### Method Names

Methods should have verb or verb phrase names.

### Don't be cute/Don't use puns

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()`

### Pick one word per concept

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.

### Solution Domain Names and Problem Domain Names

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.

### Add Meaningful Context

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

### Don't add gratuitous 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'.