Changes for page Expressive Names

Last modified by chrisby on 2023/11/18 17:45

From version 1.6
edited by chrisby
on 2023/11/18 13:45
Change comment: There is no comment for this version
To version 1.5
edited by chrisby
on 2023/11/18 13:27
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,27 +1,35 @@
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.
1 +Names should be chosen as carefully as one would name their firstborn child.
2 2  
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 -* **Avoid misinformation.** For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).
5 -* Make differences clear. Avoid very similar expressions and blank words are redundant (a, an, the, info, data).
6 -* **Use pronounceable names.** Programming is a social activity that people talk about with others.
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 -* **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.
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.
3 +**Naming Conventions**
4 +
5 +* **Choose Meaningful and Descriptive Names**
6 + * Names should be descriptive of the purpose, e.g., use `unorderedNumbers` and `orderedNumbers` instead of a generic `numbers`.
7 + * Use names that reflect the solution domain and the problem domain.
8 + * Choose one word per concept (e.g. consistently use 'fetch' for the same concept, rather than mixing 'fetch' and 'retrieve').
9 +* **Clarity and Simplicity in Names**
10 + * Names should be self-evident and avoid mental mappings or translations for clarity.
11 + * Avoid ambiguities, such as confusion with similar names or characters (e.g., l and 1, O and 0).
12 + * Make differences clear and avoid very similar expressions.
13 + * Avoid superfluous or redundant context; shorter names are better as long as they are clear.
14 +* **Practical Aspects of Naming**
15 + * Use pronounceable names so that you can easily talk with others about it.
16 + * Use searchable names, meaning names which prevent search conflicts.
17 + * The length of a name should correspond to the size of its scope. E.g. counters only used locally in loops, could be short or even single letters, but names used in a broad scope should be more descriptive and longer.
18 + * Avoid encodings, such as references to the variable's scope or type in its name.
19 +
20 +**Class and Method Naming**
21 +
22 +* **Class Names**
23 + * Should consist of nouns or noun phrases.
24 +* **Method Names**
25 + * Should consist of verbs or verb phrases.
26 + * Follow the JavaBean standard for accessors, mutators, and predicates (prefixes: get, set, is, has).
27 + * Use distinct names for overloaded constructors and prefer private constructors with distinct factory methods.
28 +
29 +**General Coding Practices**
30 +
31 +* **Avoiding Confusion and Misinformation**
32 + * Avoid humorous names, puns, and any names that might cause confusion.
33 +* **Contextual Naming**
34 + * Add meaningful context that complements other variable and method names.
35 + * Dare to rename things for clarity and improvement; colleagues should appreciate these enhancements.