Class, variable, and other namings are one of the most important things a programmer has to deal with when writing code. Not only good names will allow others to better understand your code, but also code reusability will benefit from it.
This is a compilation of recommendations for class naming:
[SO] From Implementation Patterns by Kent Beck:
- Simple Superclass Name: Pick strong metaphors for the computation the class does.
- Qualified Subclass Name: If a subclass is the root of its own hierarchy, use a simple class; if not, you can use more words to be more expressive at the cost of being less concise.
- Interfaces: Name them following the two previous points, if they are abstract interfaces. This will lead to use the best names for interfaces leaving you with somewhat strange names for subclases (File → ActualFile, ConcreteFile, FileImpl). Nevertheless, communicating if an object is abstract or concrete is usually important.
[SO] If you adhere to the Single Responsibility Principle (SRP), it should be easy to come up with good names. If a class is hard to name or explain then it’s probably not following the SRP. A class name should instantly communicate what the class is. Good names drive good designs.
Ottinger’s Rules for Variable and Class Naming (also in Clean Code’s second chapter):
- Use intention revealing names
- Avoid disinformation:
- Don’t name something a list if it’s not really a list.
- Beware of using names which vary in small ways.
- Make meaningful distinctions:
- Avoid noise words (Product vs ProductData vs ProductInfo)
- Use pronounceable names
- Use searchable names
- Avoid encodings (e.g.
- Avoid mental mapping: Strive for problem domaing terms and solution domain terms.
- Use noun and verb phrases for classes:
- Accessors can have a noun name too.
- Mutatos must not have a noun name, because they are causing something to happen.
- Pick one word for one abstract concept and stick with it
- Try to never use the same word for two purposes
- Use rich name sources
- Use solution domain names (when working in a low-level of abstraction; this includes algorithm names, data structures, CS terms, pattern names, etc.)
- Use problem domain names (When there is no programming name for what you’re doing, use the name from the problem domain)
- Add meaninful context
- Don’t add gratuitous context (like prefixing every class with the first letters of the application name)
Interesting pages from c2 wiki related to naming: