Changes for page Expressive Names

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -1,66 +1,35 @@
1		-*
	1	+Names should be chosen as carefully as one would name their firstborn child.
2	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		-*
	3	+**Naming Conventions**
7	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		-*
	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.
11	11
12		-Avoid misinformation.
13		- * For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).
14		-*
	20	+**Class and Method Naming**
15	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		-*
	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.
21	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		-*
	29	+**General Coding Practices**
25	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		-
	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.