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,27 +1,27 @@ 1 - Namesshould bechosenas carefullyas thenameof hisfirstbornchild. Implicity: It should be self-evidentfromreading the code how it works.2 - 3 - ***Choosenamesthataredescriptiveofthe purpose.**For example,a variables name shouldstand for oneconcept. Its better to have a variable`unorderedNumbers`,which is sortedandstored in`orderedNumbers` instead ofsavingboth lists inthesame variable`numbers`.4 -* **Avoid misinformation.**For example, ambiguities, confusion with similar names or easily confused characters (l and 1, O and 0).5 -* Makedifferencesclear.Avoidvery similarexpressionsandblankwordsare redundant (a,an,the,info,data).6 -* ** Use pronounceable names.** Programming is a social activitythat people talk about withothers.7 - ***Usesearchablenames.**Searchablemeans avoiding search conflicts with other similarorvenidentical names.The length ofaameshouldmatchthe sizeof itsscope.For local countingloops,one letter is sufficient; if the variableis used in several places in thecode, itneeds a longername.8 -* ** Avoid encodings.** There shouldbe noreferences to the scope or type of the variablein the name.9 - ***Avoidmentalmappings.**The nameofavariable shouldnot require mental effort tounderstand.For example, unusual abbreviationshould be avoided.10 -* Name sofclassesconsistofnouns orsubstantivisticexpressions.11 -* Method names12 - * They consistof a verb or anexpressionwith a verb.Accessors,mutators, and predicates should be namedafter their value andfollow the JavaBeanstandard (prefixes: get, set, is, has).13 - * Overloadedconstructorscanleadtoconfusion, e.g.if oneconstructoraccepts a floatargumentdand anotheroneantargument.Overloaded constructorsshouldbedeclared asprivateand functionsshould beusedtocreateinstances whose names highlightthe difference.14 -* Avoidhumorousnames.15 -* C hoose onewordper concept.16 - * "get"insteadof"fetch"and"retrieve".17 -* No puns.18 - *Avoidambiguitiesasintheword "add" (addition oradding).19 -* Use namesofthesolution domain.20 - * Programmerswill readyourcode,sousetechnical language.21 -* Use names ofthe problem domain.22 - * Iftherearenotermsfrom computer science.Then at leastdomainexpertscan referto it.23 -* Addmeaningfulcontext.24 - Together withthe names of other variables and methods, thiscontextcanbe created.25 -* Do notadd superfluouscontext.26 - * Shorternamesebetterthanlonger ones, as long astheyareclear. Namesshould besimple,butmeaningful.27 -* Dare to rename things.Your colleagues should be gratefulforimprovements.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, meaning any effort of the programmer to get the actual purpose 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.