Changes for page Expressive Names
Last modified by chrisby on 2023/11/18 17:45
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -1,29 +1,66 @@ 1 - Namesshould be chosen as carefully as the name of your first-born child. It should be obvious from reading the code how it works.1 +* 2 2 3 -#### Consistency and Standardization 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 +* 4 4 5 -* **Names of classes consist of nouns** or substantivistic expressions as they express and entity. 6 -* **Method names start with a verb** because they express an action to be performed Accessors, mutators, and predicates should be named after their value and follow the standards like the JavaBean standard (prefixes: get, set, is, has). For example, getAge(), setAge(...), isFeatureXEnabled() -> boolean, hasPermissionY() -> boolean, etc. 7 -* **Use object creation functions rather than overloaded constructors**, as the latter can cause confusion. Overloaded constructors should be declared private, and more specifically named functions should be used to create instances. 8 -* **Choose one word for each concept.** For example, if you use the word "fetch" once for a particular concept, you should consistently use "fetch" instead of synonyms such as "retrieve". 9 -* **Domain-specific terms** 10 - * Use terms from the solution domain. Programmers will be reading your code, so use technical language. 11 - * Use terms from the problem domain. If there are no computer science terms, at least domain experts can refer to them. 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 +* 12 12 13 -#### Do's 12 +Avoid misinformation. 13 + * For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0). 14 +* 14 14 15 - * **Namesdescribepurpose.** For example, it's better to have a variable `unorderedNumbers` which is sorted and thenstoredin `orderedNumbers` than to have a variable `numbers` to which thelists aressigned before and after sorting.16 - ***Usepronounceablenames.**Programmingisasocial activity that people talk about with others,so usenames that areeasy to usein conversation.17 - ***Usesearchablenames.**Searchable meansavoiding search conflictswithotherindependent thingswith the samename. The length of a name shouldmatchthe size of its scope. For localcounting loops,one letter is sufficient; if thevariable is used inmultiple places in the code,it needsalonger name.18 -* **Daretorenamethings.**Yourcolleagues shouldbegratefulforimprovements.19 -* **Add meaningful context.** By including the names of other variables and methods, this context can be created to make its purpose clearer than without context. Names can be chosen to work well with others.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 -#### Don'ts 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 +* 22 22 23 -* **Avoid misinformation.** For example, ambiguity, confusion with similar names, or easily confused characters (l and 1, O and 0). 24 -* **Avoid encodings.** There should be no references to the scope or type of the variable in the name. 25 -* **Avoid mental mappings.** The name of a variable should not require mental effort to understand. For example, unusual abbreviations should be avoided. 26 -* **No puns or humorous names.** 27 -* **Avoid ambiguities** such as the word "add", which could have the meaning of "addition" or " adding". 28 -* **Make differences clear** by avoiding very similar expressions and redundant empty words (a, an, the, info, data). 29 -* **Do not add unnecessary context.** Shorter names are better than longer ones, as long as they are clear. 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 +