Changes for page Expressive Names

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

From version 1.1
edited by chrisby
on 2023/11/17 21:51
Change comment: There is no comment for this version
To version 1.4
edited by chrisby
on 2023/11/17 22:01
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,66 +1,27 @@
1 -*
2 -
3 -Choose meaningful names.
4 - * Names should be chosen as carefully as the name of his firstborn child.
5 - * Implicity: It should be self-evident from reading the code how it works.
6 -*
7 -
8 -Choose names that are descriptive of the purpose.
9 - * 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.
10 -*
11 -
12 -Avoid misinformation.
13 - * For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).
14 -*
15 -
16 -Make differences clear.
17 - * Avoid very similar expressions.
18 - * Blank words are redundant (a, an, the, info, data).
19 -* Use pronounceable names. Programming is a social activity that people talk about with others.
20 -*
21 -
22 -Use searchable names.
23 - * The length of a name should correspond to the size of its scope. For local counting loops, one letter is enough; if the variable is used in multiple places in the code, it needs a longer name.
24 -*
25 -
26 -Avoid encodings.
27 - * There should be no references to the scope or type of the variable in the name.
28 -*
29 -
30 -Avoid mental mappings.
31 - * The name of a variable should not have to be mentally translated into another. Clarity has absolute priority.
32 -*
33 -
34 -Class names
35 - * Names of classes consist of nouns or substantivistic expressions.
36 -*
37 -
38 -Method names
39 - * 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).
40 - * Overloaded constructors can lead to confusion, e.g. if a float is to be passed once and an int once. Constructors should be declared as private and functions should be used to create instances whose names highlight the difference.
41 -* Avoid humorous names.
42 -*
43 -
44 -Choose one word per concept.
45 - * "get" instead of "fetch" and "retrieve".
46 -* No puns.
47 -* Avoid ambiguities as in the word "add" (addition or adding).
48 -*
49 -
50 -Use names of the solution domain.
51 - * Programmers will read your code, so use technical language.
52 -*
53 -
54 -Use names of the problem domain.
55 - * If there are no terms from computer science. Then at least domain experts can refer to it.
56 -*
57 -
58 -Add meaningful context.
59 - * Together with the names of other variables and methods, this context can be created.
60 -*
61 -
62 -Do not add superfluous context.
63 - * Shorter names are better than longer ones, as long as they are clear. Names should be simple, but meaningful.
64 -* Dare to rename things. Your colleagues should be grateful for improvements.
65 -
66 -
1 +* **Meaningful and Descriptive Names**
2 + * Choose names carefully, as if naming a child.
3 + * Names should reflect the code's purpose clearly. For example, use `unorderedNumbers` and `orderedNumbers` instead of a generic `numbers`.
4 +* **Avoid Misinformation**
5 + * Steer clear of ambiguous, easily confused names or characters (e.g., l vs. 1, O vs. 0).
6 +* **Clarity in Differences**
7 + * Distinguish names distinctly, avoiding similar expressions and redundant words (e.g., a, an, the, info, data).
8 +* **Pronounceable and Searchable Names**
9 + * Use names that are easy to pronounce and discuss.
10 + * Name length should match its scope: short for local loops, longer for broader usage.
11 +* **No Encodings or Mental Mappings**
12 + * Avoid including type or scope information in names.
13 + * Names should be clear without requiring mental translation, meaning any effort of the programmer to get the actual purpose
14 +* **Naming Conventions for Classes and Methods**
15 + * Class names: Use nouns or noun phrases.
16 + * Method names: Use verbs or verb phrases, adhering to standards like JavaBean (get, set, is, has). Utilize descriptive function names instead of overloaded constructors.
17 +* **Avoid Inappropriate Humor and Ambiguities**
18 + * Refrain from humorous names.
19 + * Choose one word per concept to maintain consistency (e.g., always use "get" instead of alternating with "fetch" or "retrieve").
20 + * Avoid puns and ambiguous terms (like "add" for addition or appending).
21 +* **Domain-Specific Naming**
22 + * Use technical terms (solution domain) for clarity among programmers.
23 + * Use terms from the problem domain when no technical equivalents exist, aiding domain experts.
24 +* **Context and Simplicity in Naming**
25 + * Provide meaningful context through combined variable and method names.
26 + * Avoid unnecessary context; opt for shorter, meaningful names.
27 + * Be open to renaming for clarity and improvement.