Changes for page Expressive Names

Summary

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

Details

Page properties

Content

...	...	@@ -1,66 +1,27 @@
1		-*
	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		-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
	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
39	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.
	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.
41	41	* Avoid humorous names.
42		-*
43		-
44		-Choose one word per concept.
	15	+* Choose one word per concept.
45	45	* "get" instead of "fetch" and "retrieve".
46	46	* No puns.
47	47	* Avoid ambiguities as in the word "add" (addition or adding).
48		-*
49		-
50		-Use names of the solution domain.
	19	+* Use names of the solution domain.
51	51	* Programmers will read your code, so use technical language.
52		-*
53		-
54		-Use names of the problem domain.
	21	+* Use names of the problem domain.
55	55	* If there are no terms from computer science. Then at least domain experts can refer to it.
56		-*
57		-
58		-Add meaningful context.
	23	+* Add meaningful context.
59	59	* Together with the names of other variables and methods, this context can be created.
60		-*
61		-
62		-Do not add superfluous context.
	25	+* Do not add superfluous context.
63	63	* Shorter names are better than longer ones, as long as they are clear. Names should be simple, but meaningful.
64	64	* Dare to rename things. Your colleagues should be grateful for improvements.
65		-
66		-