Changes for page Expressive Names

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

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

Summary

Details

Page properties
Content
... ... @@ -1,27 +1,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.
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.
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 +