Meaningful naming conventions

Use intention-revealing names

• Choosing good names takes time but saves more than it takes.
• Take care with your names and change them when you find better ones.
• The name of a variable, function or class should answer the big questions such as why it exists, what it does, how it is used.
• If a name requires a comment, then the name does not reveal its intent.
• Give names to concepts, from the context, to make the purpose of the code more explicit.

Avoid Disinformation

• Avoid leaving false clues that obscure the meaning of code. For example using words whose entrenched meaning vary from our intended meaning, such as using hp for the concept of a hypotenuse, because “hp” is a well-entrenched name.
• As another example, do not use accountList unless it is actually a Java List. Use something else instead, such as accountGroup.
• Avoid using names that vary only in small ways
• Spelling similar concepts in similar ways is good – it is informative. Using inconsistent spelling, however, is disinformation.
• It is very helpful if names for very similar things sort together alphabetically, and if the differences are very obvious.

Make meaningful distinctions

• Distinguish names in such a way that the reader knows what the differences offer. For example, the two classes ProductInfo and ProductData have different names but the names don’t mean anything different, because here Info and Data are indistinct noise words.

Use pronounceable names

• Our minds have evolved to deal with spoken language, so take advantage of that when creating names.
• Also, if you can’t pronounce it, you can’t discuss it without sounding like an idiot.

Use searchable names

• Names should be easy to locate across a body of text.
• If a variable or constant might be seen or used in multiple places in a body of code, it is imperative to give it a search-friendly name.
• Single-letter names should ONLY be used as local variables inside short methods.

Pick one word per concept

• Pick and use one word for abstract concept and stick with it.
• A consistent lexicon is a great boon to the programmers who use your code.

Don’t put everything in the same

• Don’t deliberately or inadvertently re-use the same term where its sematic meaning in the code is different.
• Avoid over-used cliches, e.g. value, result, tmp. Use them when they mean themselves.

Move simple comments into variable names

Variable names can not(and should not) replace all comment, but if a short comment can fit into the variable name, that’s acceptable.

Use Idioms where meaning is obvious

There are some idioms that are so widely-understood and unabused that they’re safe to use, e.g. use i, j and k in straightforward for loops

May use short names over short distances when obvious

A long variable name catch a reviewer’s attention. If part of the variable name is useless, remove it. It’s okay if two or three words could obviously convert the variable’s meaning.

Class names

• Classes and objects should have noun or noun-phrase names, like Customer, WikiPage, Account and AddressParser.
• But avoid names like Manager, Processor, Data or Info in the name of a class.
• A class name should not be a verb.

Method names

• Methods should have verb or verb-phrase names, like deletePage or save.
• Accessors and mutators, and their predicates, should be named according to JavaBean standards.
• Try to name methods with “has” etc, which return boolean value

Variable names

The variable names should be as descriptive as possible. Don’t use generic names. Variable names should start with nouns, following the form adj-noun, noun-noun and noun-verb (probably acceptable). For Boolean variables, try to name them with “is”