Wiki source code of Expressive Names
Hide last authors
author | version | line-number | content |
---|---|---|---|
![]() |
1.7 | 1 | Names should be chosen as carefully as the name of your first-born child. It should be obvious from reading the code how it works. |
![]() |
1.5 | 2 | |
![]() |
1.10 | 3 | * **Names describe purpose.** For example, it's better to have a variable `unorderedNumbers`, which is sorted and stored in `orderedNumbers` instead of saving both lists in the same variable `numbers`. |
![]() |
1.6 | 4 | * **Avoid misinformation.** For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0). |
![]() |
1.10 | 5 | * **Make differences clear.** Avoid very similar expressions and blank words are redundant (a, an, the, info, data). |
![]() |
1.6 | 6 | * **Use pronounceable names.** Programming is a social activity that people talk about with others. |
![]() |
1.11 | 7 | * **Use searchable names.** Searchable means avoiding search conflicts with other independent things with the same name. The length of a name should match the size of its scope. For local counting loops, one letter is sufficient; if the variable is used in several places in the code, it needs a longer name. |
![]() |
1.6 | 8 | * **Avoid encodings.** There should be no references to the scope or type of the variable in the name. |
9 | * **Avoid mental mappings.** The name of a variable should not require mental effort to understand. For example, unusual abbreviations should be avoided. | ||
![]() |
1.8 | 10 | * **Names of classes consist of nouns** or substantivistic expressions. |
![]() |
1.10 | 11 | * **Method names** **consist of a verb** or an expression with a verb. Accessors, mutators, and predicates should be named after their value and follow the JavaBean standard (prefixes: get, set, is, has). For example, getAge(), setAge(...), isFeatureXEnabled() -> boolean, hasPermission() -> boolean etc. |
![]() |
1.9 | 12 | * **Use object creation functions rather than overloaded constructors**, as the latter can cause confusion. Overloaded constructors should be declared private, and functions should be used to create instances whose names make the difference clear. |
![]() |
1.8 | 13 | * **No puns or humorous names.** |
14 | * **Choose one word for each concept.** For example, if you use the word "fetch" once for a particular concept, you should consistently use "fetch" instead of synonyms such as "retrieve". | ||
15 | * **Avoid ambiguities** as in the word "add" (addition or adding). | ||
16 | * **Domain-specific terms** | ||
![]() |
1.7 | 17 | * Use terms from the solution domain. Programmers will be reading your code, so use technical language. |
18 | * Use terms from the problem domain. If there are no computer science terms, at least domain experts can refer to them. | ||
![]() |
1.8 | 19 | * **Add meaningful context.** Together with the names of other variables and methods, this context can be created. |
20 | * **Do not add superfluous context.** Shorter names are better than longer ones, as long as they are clear. | ||
21 | * **Dare to rename things.** Your colleagues should be grateful for improvements. |