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

1. Use Names That Express Intent

Names should tell us what it does, why it exists, and how it works. Choosing intention-revealing names will make it easier for us to understand the code.

int d; // elapsed time in days

int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;

In the snippet above, we can only know what the variable d refers to from the comment. So readers of the code have to search for its instances to get clues in order to understand its meaning. Therefore, if we can name this variable well, readers of the code will instantly know its meaning.

2. Don't Be Afraid to Spend Time Choosing Names

You should try several different names until they sufficiently describe their meaning, and never be afraid to spend time on this. Those who later read your code (including yourself) will benefit from it. In addition, a descriptive name can even help you clarify the design of the module in your mind. Good naming does take time, but in the long run, the benefits outweigh the costs.

3. Refactor Names

If you think of a better name later in development, don't hesitate—go ahead and change it. Today's IDEs make renaming extremely easy.

4. Avoid Noise Words in Names

For example,Manager、Processor、Data、Infoand synonyms of "I don't know what to call this" are all noise words. If you need to use these noise words, it means your naming may be too redundant.

5. Beware of Classes/Functions That Are Hard to Name

A class or function that is hard to name is likely a code smell. It indicates that:

• The code does too much.
• The code does too little.
• You do not understand the problem well enough yet and need to gather more information.

6. Class Names

Classes should have names that are nouns or noun phrases, such asCustomer、WikiPage、AccountandAddressParserInheritance superclasses should be given short, punchy names. Subclass names should be longer, using adjectives to describe how they differ from their superclass, such asSavingsAccountderived from Account.

7. Variable Names

Variable names should also be nouns. Most are derived from the class they refer to. Boolean variables should be written as predicates, such asisEmptyandisTerminated, which makes them easier to understand in if statements.

8. Method Names

Method names should be a verb or verb phrase, such aspostPayment()、deletePage()andsave()Accessors and mutators should be prefixed with get and set respectively. Methods that return booleans should be prefixed with 'is', such as isPostable(), so that they are easy to understand in if statements.

9. Scope Size and Variable Name Length

The length of a variable name should match its scope size. If the variable has a small scope, its name should be short. Conversely, the name should be longer and more descriptive.

10. Scope Size and Method/Class Name Length

For methods and classes, however, name length should be inversely proportional to scope. For public methods, shorter names are better because they are called many times. Private methods are only called within the class, so longer names can serve as documentation. The exception to this rule is derived class names. The more derived a class is, the more adjectives are added before the base class, and the longer the name becomes.

11. One Concept One Word

Pick one word for an abstract concept and then don't change it. For example, as equivalent methods in different classes,get()、fetch()andretrieve()can be confusing. Consistent vocabulary is an important tool for programmers to manage code.

12. Don't Use the Same Word for Two Different Concepts

If you follow point 11—the principle of one concept, one word—you can avoid many classes with the same method name. As long as the parameter lists and return values of the various methods are semantically equivalent, there is no problem. Problems only arise when you use the same word for two different concepts.

For example, we can useadd()method in multiple classes to create a new value by adding or concatenating two existing values. If later we need to introduce an add method in a class to add a parameter to a collection, this will cause problems due to different semantics. It would be better to rename this new method to insert().

13. Use Solution Domain Names

15. Add Meaningful Context

Most names are meaningless by themselves and need to be placed in a context (class/function/namespace) for readers to understand what they refer to. In some cases, it may be necessary to prefix names to add context. For example, suppose we have some variables used to represent an address:firstName、lastName、street、houseNumber、city、stateandzip. If we only look at the variable state, it is difficult to infer what it means. A better solution is to encapsulate these variables in an Address class.

16. Don't Add Unwarranted Context

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

17. Avoid Encoding

Given the power of today's IDEs, we no longer need to encode type and scope information into variable names and class names. This includes not needing to add 'I' to interfaces, because users of the code don't need to know that their class is being passed to an interface. So if you must use encoding, it is better to encode the implementation rather than the interface.

18. Avoid Misleading Information

Don't give misleading information, because it will mislead readers of the code. If you name a variable that actually holds an array as accountList, it is easy for people to draw the wrong conclusion.

19. Avoid Unpronounceable Names

Programming is a social activity; using unpronounceable names will only hinder our discussions.

20. Use Easily Searchable Names

Using short, generic names makes it difficult to search for things in the codebase. This has a great impact on our ability to manipulate the code and refactor.

Finally, if you have different opinions, please feel free to share them.

Source: http://www.codeceo.com/article/20-naming-tips-programmer-know.html