20 code naming tips per programmer-Other integrated

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

1. Use a name that can express intent

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

int D; Elapsed time in the days

int elapsedtimeindays;
int dayssincecreation;
int dayssincemodification;
int fileageindays;

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

2. Don't be afraid to take the time to choose a name
you should try several different names until it is enough to describe the meaning, and don't be afraid to spend time on it. People who read your code in the future (including yourself) will benefit from it. In addition, a descriptive name can even help you to clarify the design of the module in your mind. Good naming does take time, but in the long run, the benefits outweigh the disadvantages.

3. Refactoring names
If you think of a better name later in the development process, do not hesitate to change it immediately. The IDE now makes it extremely easy to refactor names.

4. Avoid interfering words in names
For example, Manager, Processor, Data, info, and "I don't know what this is called" synonym, are all interference words. If you need to use the above noise words, then your name may be too cumbersome.

5. Beware of difficult to name classes/functions
a class or function that is difficult to name is likely to be a code odor. This explains:

The code is doing too much.
The code isn't doing enough.
Your understanding of this problem is not thorough enough to get more information first.
6. Class name
class should have the name of a noun or noun phrase, such as customer, Wikipage, account, and Addressparser. The inherited parent class should give a short, high-impact name. The name of a subclass should be long, using an adjective to describe its difference from its parent class, such as SavingsAccount derived from account.

7. Variable Name
variable names should also be nouns. Most of them are 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 (). The accessor and the regulator should prefix get and set respectively. The method that returns a Boolean value should prefix ' is ', such as ispostable (), so that it is easy to understand in the IF statement.

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

10. Range size and Method/class name length
the length of the method and class name should be inversely proportional to its scope. For public methods, shorter names are better because they are called multiple times. Private methods are invoked only within the scope of a class, and longer names can be used as documents. The exception to this rule is the name of the derived class. The more the class derives, the more adjectives the base class will add, and the longer the name will be.

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 () are confusing. Keeping 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 principle of the 11th-a concept-a word, you can avoid many classes that have the same method name. This is fine as long as the argument list and the return values of the various methods are semantically equivalent. Problems can only occur if 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 in the class to add parameters to the collection, this can cause problems because of the different semantics. This new method is best called insert ().

13. Use the name of the solution domain
The code we write may be read by other programmers in the future, so it's great to use some technical terminology for code naming. For example, the proper use of algorithm names, design pattern names, and mathematical terminology is likely to 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. This will provide clues to the problem when the programmer who reads your code in the future is unsure of the meaning of the code.

15. Add a meaningful context
most of the names themselves are meaningless and need to be put into context (class/function/namespace) in order for the person reading the code to understand what they are referring to. In some cases, prefix names may be required to complement the context. For example, suppose we have some variables used to represent addresses: FirstName, LastName, Street, Housenumber, city, state, and zip. If we look at the state variable, it's hard to infer what it means, and a better solution is to encapsulate the variables into the address class.

16. Do not add an unwarranted context
as long as the meaning is clear, a shorter name is usually better than a long one, so don't add the context in a superfluous way. Names should not be prefix 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 the encoding type and scope information to the variable name and class name. This includes not having to add the I to interface because users who use code do not need to know that their classes are being passed to the interface. So if you have to use coding, it's best to encode the implementation instead of the interface.

18. Avoid the wrong information
don't give the wrong information, because it will mislead the person reading the code. If you name a variable that actually supports an array as accountlist, it's easy to draw the wrong conclusion.

19. Use a name that can't be read
programming is a social activity, and using names that can't be read will only hinder our discussion.

20. Use the Easy Search name
using short, generic names prevents us from searching the code base for things. This has an impact on our manipulation of code and refactoring.

Finally, if you have different views, please do not hesitate to enlighten me.

Translation Links: http://www.codeceo.com/article/20-naming-tips-programmer-know.html
Tips for Better naming
Translation Author: Code Rural network – Xiao Feng