Skip to Content

Changes for page Expressive Names

Last modified by chrisby on 2023/11/18 17:45
From version 1.9
edited by chrisby
on 2023/11/18 16:19
Change comment: There is no comment for this version
To version 1.6
edited by chrisby
on 2023/11/18 13:45
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,4 +1,4 @@
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 +Names should be chosen as carefully as the name of his firstborn child. Implicity: It should be self-evident from reading the code how it works.
2 2  
3 3  * **Choose names that are descriptive of the purpose.** For example, a variables name should stand for one concept. Its better to have a variable `unorderedNumbers`, which is sorted and stored in `orderedNumbers` instead of saving both lists in the same variable `numbers`.
4 4  * **Avoid misinformation.** For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).
... ... @@ -7,15 +7,21 @@
7 7  * **Use searchable names.** Searchable means avoiding search conflicts with other similar or even identical names. 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.
8 8  * **Avoid encodings.** There should be no references to the scope or type of the variable in the name.
9 9  * **Avoid mental mappings.** The name of a variable should not require mental effort to understand. For example, unusual abbreviations should be avoided.
10 -* **Names of classes consist of nouns** or substantivistic expressions.
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).
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.
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**
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.
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.
10 +* Names of classes consist of nouns or substantivistic expressions.
11 +* Method names
12 + * They 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).
13 + * Overloaded constructors can lead to confusion, e.g. if one constructor accepts a float argument and and another one an int argument. Overloaded constructors should be declared as private and functions should be used to create instances whose names highlight the difference.
14 +* Avoid humorous names.
15 +* Choose one word per concept.
16 + * "get" instead of "fetch" and "retrieve".
17 +* No puns.
18 +* Avoid ambiguities as in the word "add" (addition or adding).
19 +* Use names of the solution domain.
20 + * Programmers will read your code, so use technical language.
21 +* Use names of the problem domain.
22 + * If there are no terms from computer science. Then at least domain experts can refer to it.
23 +* Add meaningful context.
24 + * Together with the names of other variables and methods, this context can be created.
25 +* Do not add superfluous context.
26 + * Shorter names are better than longer ones, as long as they are clear. Names should be simple, but meaningful.
27 +* Dare to rename things. Your colleagues should be grateful for improvements.