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 ability.

1. Use names that reveal intent

A name should tell us what it does, why it exists, and how it works. Choosing names that reveal intent makes 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 from the comment what the variable d refers to. Readers of the code therefore have to search for its instances to get clues. So if we name this variable well, readers can instantly know what it means.

2. Don't be afraid to spend time choosing names

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

3. Refactor names

If you come up with a better name later in development, don't hesitate to change it right away. Today's IDEs make refactoring names extremely easy.

4. Avoid noise words in names

For example,Manager、Processor、Data、Infoand synonyms of "I don't know what this is called" are noise words. If you need to use these noise words, it means your naming is probably too verbose.

5. Be wary of classes/functions that are hard to name

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

• The code does too much.
• The code does too little.
• You don't understand the problem thoroughly enough and need to gather more information first.

6. Class names

Classes should have a noun or noun phrase as their name, such asCustomer、WikiPage、AccountandAddressParserSuperclasses should have short, impactful names. Subclasses should have longer names, using adjectives to describe how they differ from their superclass, such asSavingsAccountderived from Account.

7. Variable names

Variable names should also be nouns. They are mostly derived from the class they reference. Boolean variables should be written in predicate form, such asisEmptyandisTerminatedso that they are 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 a boolean should be prefixed with 'is', such as isPostable(), so that they are easier to understand in if statements.

9. Scope size and variable name length

The length of a variable name should match its scope. If the scope is short, the variable name should be short as well. Conversely, the variable name should be longer and more descriptive.

10. Scope size and method/class name length

The length of method and class names should be inversely proportional to their scope. For public methods, shorter names are better because they will be 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, for equivalent methods in different classes,get()、fetch()andretrieve()changing the word would confuse people.

12. Don't use the same word for two different concepts

If you follow tip 11 — one concept, one word — you can avoid many classes with the same method names. As long as the parameter lists and return values of the 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 use theadd()method to create a new value by adding or concatenating two existing values. If later we need to introduce an add method in the class to add a parameter to a collection, this will cause problems because of different semantics. It would be better to name this new method insert().

13. Use names from the solution domain

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, you may need to prefix the name to add context. For example, suppose we have some variables representing an address:firstName、lastName、street、houseNumber、city、stateandzipIf we look only at the state variable, it is difficult to infer what it refers to. A better solution is to encapsulate these variables in an Address class.

16. Don't add gratuitous 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 modern IDEs, we no longer need to encode type and scope information into variable names and class names. This includes not having to add 'I' to interfaces, because users of the code don't need to know that their classes are being passed to an interface. So if you must use encoding, it is better to encode implementations rather than interfaces.

18. Avoid misleading information

Don't give wrong information, as it will mislead people reading 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. Use unpronounceable names

Programming is a social activity. Using unpronounceable names will only hinder our discussion.

20. Use searchable names

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

Finally, if you have any different opinions, please don't hesitate to share them.

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