20 code names to be mastered by each programmer

The code has to be named everywhere. As programmers, we have to name the class, name the variables, name the functions, name the parameters, name the namespaces, and so on. Here are 20 tips to help you improve your naming skills.

1. Use a name that expresses intent

The name can tell us what it is going to do, why it exists, and how it works. Choosing a name that can express your intentions will help us understand the code better.

int elapsedtimeindays;   int dayssincecreation;   int dayssincemodification;   int fileageindays;</span>  

In the above fragment, we can only tell from the note what the variable D refers to. So the person who reads the code has to find an instance of it to get clues in order to know its meaning. So, if we can name this variable well, the person reading the code can instantly know what the variable means.

2. Don't be afraid to take the time to choose a name

You should try several different names until they are enough to describe what they mean, and don't be afraid to spend time on them. The people who read your code later (including yourself) will benefit from it. In addition, a descriptive name can even help you clarify the design of the module in mind. Good naming does take time, but in the long run, the benefits outweigh the disadvantages.

3. Refactoring the name

If you think of a better name at the end of the development process, don't hesitate to change it right away. Now the IDE makes refactoring the name incredibly easy.

4. Avoid the occurrence of noise words in the name

For example, Manager, Processor, Data, info, and the synonyms "I don't know what this is called" are noise words. If you need to use these noise words, then your name may be too cumbersome.

5. Be careful with difficult-to-name classes/functions

A class or function that is hard to name is most likely a code odor. This shows:

• The code is doing too much.
• The code is not doing enough.
• You do not understand this problem thoroughly enough, you need to get more information first.

6. Class Name

The class should have a noun or noun phrase name, such as customer, Wikipage, account, and Addressparser. The inherited parent class should give a short, impactful name. The name of the subclass should be long, with adjectives describing it as distinct from its parent class, such as SavingsAccount derived from account.

7. Variable Name

The variable name should also be a noun. They are mostly derived from the classes they point to. Boolean variables should be written in the form of predicates, such as IsEmpty and isterminated, so that the IF statement is easy to understand.

8. Method name

The method name should be a verb or verb phrase, such as postpayment (), Deletepage (), and Save (). Accessors and the regulator should prefix get and set separately. The method that returns a Boolean value should be prefixed with ' is ', such as ispostable (), so that it is easy to understand in the IF statement.

9. Range size and length of variable names

The length of the variable name should match its range size. If the range of variables is short, then the length of the variable name should also be very short. Conversely, the variable name should be longer and more descriptive.

10. Range size and length of method/class name

The length of the method and class name should be inversely proportional to its scope. For public methods, shorter names would be better, because they would be called multiple times. A private method is called only within the scope of the class, and a longer name can be used as a document instead. The exception to this rule is the name of the derived class. The more derived the class, the more adjectives are added before the base class, and the longer the name.

11. A concept a word

Select a word for an abstract concept, and then don't change it. For example, as an equivalent in a non-homogeneous way, get (), Fetch (), and retrieve () can confuse people. Maintaining a consistent vocabulary is an important tool for programmers to harness code.

12. Do not use the same word for two different concepts

If you follow the 11th-the principle of a concept-one word, you can avoid many classes that have the same method name. As long as the parameter list and the return values of the various methods are semantically equivalent, there is no problem. The problem only occurs when you use the same word for two different concepts.

For example, we can use the Add () method in multiple classes to create a new value by adding or connecting two existing values. If we later need to introduce an Add method to the class to add parameters to the collection, this can cause problems because of different semantics. This new method is best called insert ().

13. Use the name of the solution area

The code we write may be read by other programmers in the future, so we have a great advantage in using some technical terminology for code naming. For example, proper use of algorithmic names, design pattern names, and mathematical terminology may well make it easier for other programmers to understand the program and resonate.

14. Use the name of the problem domain

If you can't find an easy-to-understand technical term to name, you can also find the right code name from the problem area. When programmers who read your code in the future are unsure of the meaning of the code, this will give them clues to the problem.

15. Add a meaningful context

Most names are meaningless in themselves and need to be put into context (classes/functions/namespaces) in order for the person reading the code to understand what they refer to. In some cases, a prefix name may be required to complement the context. For example, suppose we have some variables to represent addresses: FirstName, LastName, Street, Housenumber, city, state, and zip. If you look at the state variable, it is difficult to infer what it means, and a better solution is to encapsulate these variables in the address class.

16. Do not add an unwarranted context

As long as the meaning is clear, shorter names are usually better than long, so don't superfluous to add context. Names should not be prefixed with unnecessary information that can be inferred from the class/package/namespace.

17. Avoid coding

Given the power of the IDE now, we don't need to encode type and range information into variable names and class names. This includes the need to add I-to-interfaces, because users who use code do not need to know that their classes are being passed to the interface. So if you must use coding, then it is best to encode the implementation instead of the interface.

18. Avoid the wrong information

Don't give some wrong information because it will mislead people who read the code. If you name a variable that actually supports arrays as accountlist, it's easy to draw a wrong conclusion.

19. Use a name that cannot be read

Programming is a social activity, and using names that can't be read only hinders our discussion.

20. Use easy-to-search names

Using short, generic names can prevent us from searching for things in the code base. This has an impact on our manipulation of code and refactoring.

Finally, your code can be completed perfectly, of course, there are other important steps, that is to add shell code, that is, encryption protection! Do not let yourself hard to write out the code to develop a good program for others to use, prevention!

Ext.: http://blog.csdn.net/lz201234/article/details/44774647

20 code names to be mastered by each programmer