This journal is a summary of a reading material. File: Https://class.stanford.edu/c4x/Engineering/CS-144/asset/Naming.pdf (also available from Baidu cloud disk Download: http://pan.baidu.com/s/1hqf6KIw). Summarized as follows:
- The name should reflect the purpose of the code author.
-
- This saves unnecessary annotations such as int t; Time since born in days can be changed to int dayssinceborn;) and make the code easier to read. easy to read and easy to discuss with each other, this will be the focus of all of the following naming conventions . Another issue to note about annotations: When time is tense, not many people read the comments, but the name guesses the meaning.
- Avoid magic numbers, replace numbers with macro definitions, avoid ' inexplicable operations ', and read all kinds of judgment or loop control statements as if they were normal sentences.
- Avoid ambiguity.
-
- There are some combinations of letters in computer science because it is widely known that all have a conventional meaning, such as hp,aix,list. So a "namelist" variable will immediately give the impression that "this is a linked list", and if it is not actually a list, then "Accountgroup" is a better name.
- Another reason for ambiguity is that two names look much like each other. For example, "Thisisonename" and "thisisonname" difference between small and should not be seen at a glance. In addition, the lowercase L (l) and 1 are similar in some editors, and 0 and O are the same; Pay attention to this problem.
- There should be a clear distinction between the meanings of different names. such as "Stellarinfo" and "stellardata" in the meaning of no difference, if used to represent two different things, it is easy for users (themselves or others) to use the wrong. This can be thought of as a variant of the above-mentioned ' ambiguity ' (not conflicting with the name of the contract, but semantically conflicting with your own other name).
- In relation to the above, a concept should use the same word. For example, there are two classes, dog and cat, so using ' feet ' and ' paws ' to say "dog claw" and "Cat's Paw" is not a good habit, because you have to remember exactly which dog and cat corresponds to feet. But--
- If a word has different meanings for different objects, it cannot be used for ' consistency ', but should be the most appropriate name for a particular type. For example, two numbers added, with ' add ', adding elements to a list may seem to use ' add ', but the meaning is significantly different from the above two ' add '. Therefore, the ' append ' should be considered.
- Use a name that can be spelt. For example, "tpshms" can not spell, so in the discussion with other programmers, can only "tee-pee-es-aich-em-es" such a letter, a letter, time-consuming and laborious, on the contrary, "userId" agreed.
- Names should be easy to search. This has obvious practical significance: quickly locating to the definition of a variable of interest is critical to an efficient understanding of a piece of code. Variable names that are not easy to search include separate numbers and strings with fewer letters. For example, 5 This number is difficult to grep to the target location, but define a macro: Min_element_number is easy to search. In principle the length of the name should be roughly proportional to the code length of the field in which it resides, but in any case, try to use a descriptive strong name.
- Do not use a prefix that represents a type. Hungarian nomenclature is useful in times of less data types, but modern programming languages, types, and can be nested, with Hungarian nomenclature or similar nomenclature, will only lead to many prefixes that are not easily pronounced and are inherently non-caring. Bottom line: Just focus on the meaning of the variable when you name it, and don't control its type.
- Avoid meaningless naming. Using i,j,k as a cyclic indicator is a bad habit. They don't make any sense.
- Don't be a smart fool. For example, the use of unique allusions (#define HU_LU_WA 7); But people who read the code may come from different cultures, completely ignorant of the humor inside, and thus only lead to confusion. Can't help writing, put humor in the comments, not busy people may read.
- Use the appropriate verb-noun structure. For example, a method of a class can be named GetName (the first word in lowercase, the first letter of the word, called camel casing); The name change operation can be ' Fred '. Changenameto ("Mike"), Notice that there's even a preposition in it. to--purpose is only one: Make a function statement like a normal sentence.
- Identify two types of naming methods. A class of named reaction technical details, a class of naming describes a particular object. The basic spirit is that the outermost function located in the software structure should reflect more on the nature of the object itself, such as car.weight () or star.age (), while the underlying implementation should be related to the solution-this is natural because the underlying implementation is usually not dependent on the specific object, such as functions in commonly used libraries.
- Add context to variable names that may cause ambiguity. For example, a variable named tree, it is difficult to determine whether it is a data structure of the various trees, or a tree in the forest. The solution is to put it in a class/namespace/function, or prefix it with a method, such as Oak_tree.
- Do not add a meaningless prefix. For example, you want to write a gateway software to the school, the address named Sjtuaddress is not a good habit, because all the variables have sjtu this property, so simply do not write.
- A point related to the above: the more descriptive the better, does not mean that the more letters in the name the better; in fact, in the same clear case, the fewer letters the better.
- If you find that the name of the previous code is unreasonable, do not take action because of the fear that ' other programmers may complain '. In fact, in general, they will thank you for changing your name to a more reasonable place.
Code Naming conventions