Changes for page Expressive Names

Summary

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

Details

Page properties

Content

...	...	@@ -1,45 +1,66 @@
1		-1.
	1	+*
2	2
3		-**Meaningful and Descriptive Names**
4		- * Choose names carefully, as if naming a child.
5		- * Names should reflect the code's purpose clearly. For example, use unorderedNumbers and orderedNumbers instead of a generic numbers.
6		-1.
	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	7
8		-**Avoid Misinformation**
9		- * Steer clear of ambiguous, easily confused names or characters (e.g., l vs. 1, O vs. 0).
10		-1.
	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	11
12		-**Clarity in Differences**
13		- * Distinguish names distinctly, avoiding similar expressions and redundant words (e.g., a, an, the, info, data).
14		-1.
	12	+Avoid misinformation.
	13	+ * For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).
	14	+*
15	15
16		-**Pronounceable and Searchable Names**
17		- * Use names that are easy to pronounce and discuss.
18		- * Name length should match its scope: short for local loops, longer for broader usage.
19		-1.
	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	+*
20	20
21		-**No Encodings or Mental Mappings**
22		- * Avoid including type or scope information in names.
23		- * Names should be clear without requiring mental translation.
24		-1.
	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	25
26		-**Naming Conventions for Classes and Methods**
27		- * Class names: Use nouns or noun phrases.
28		- * Method names: Use verbs or verb phrases, adhering to standards like JavaBean (get, set, is, has). Utilize descriptive function names instead of overloaded constructors.
29		-1.
	26	+Avoid encodings.
	27	+ * There should be no references to the scope or type of the variable in the name.
	28	+*
30	30
31		-**Avoid Inappropriate Humor and Ambiguities**
32		- * Refrain from humorous names.
33		- * Choose one word per concept to maintain consistency (e.g., always use "get" instead of alternating with "fetch" or "retrieve").
34		- * Avoid puns and ambiguous terms (like "add" for addition or appending).
35		-1.
	30	+Avoid mental mappings.
	31	+ * The name of a variable should not have to be mentally translated into another. Clarity has absolute priority.
	32	+*
36	36
37		-**Domain-Specific Naming**
38		- * Use technical terms (solution domain) for clarity among programmers.
39		- * Use terms from the problem domain when no technical equivalents exist, aiding domain experts.
40		-1.
	34	+Class names
	35	+ * Names of classes consist of nouns or substantivistic expressions.
	36	+*
41	41
42		-**Context and Simplicity in Naming**
43		- * Provide meaningful context through combined variable and method names.
44		- * Avoid unnecessary context; opt for shorter, meaningful names.
45		- * Be open to renaming for clarity and improvement.
	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	+