In the article On Names we showed that having an accurate name for domain objects is essential to provide scope and control. Now we want to concentrate on how to find names and use them consistently in our projects.

We will have a look at the language we use in our projects and provide rules how to use names in our code while adhering to naming conventions.

...

In Chapter 2 of Clean Code, Tim Ottinger writes a lot of detailed information about Meaningful Names. He covers the following concepts:

1. Use Intention-Revealing Names - The goal here is defined in the quote above, but since this is - in our view - the most important point, we cite it again: "The name of the variable, function, or class, should answer all the big questions. It should tell you why it exists, what is does, and how it is used." (p. 18)
2. Avoid Disinformation - "Programmers must avoid leaving false clues that obscure the meaning of code. [...] Beware of names which vary in small ways. [...] Spelling similar concepts similarly is information. Using inconsistent spelling is disinformation." (p. 19f)
3. Make Meaningful Distinctions - do not introduce an arbitrary name for the same concept just to distinguish two of them in a given context. Try hard to find the difference and provide meaningful name.
4. Use Pronounceable Names - since they are part of the Ubiquitous Language each team member has to use them when they speak to each other.
5. Use Searchable Names - if you want to search for a particular name, names like e or list are not easily searchable.
6. Avoid Encodings - these make the domain language more complicated in the code. p_customer for a private field? IPhone for an interface for a phone? Also do not use suffixes like Impl. Name what the intention of the artifact is.
7. Avoid Mental Mapping - do not use a meaningless name that has to be mapped to a construct of the domain by a programmer. Programmers should write code that others can easily understand.
8. Don't Be Cute - this also takes place if a name is not taken from the Ubiquitous Language. Do not use slang or cultural dependent names. "Say what you mean. Mean what you say." (p. 26)
9. Pick One Word per Concept - the glossary will help.
10. Don't Pun - "[a]void using the same word for two purposes." (p. 26)
11. Use Solution Domain Names - it is a good practice to use terms from the solution domain, like names from pattern (e.g. Factory) or common programming constructs (like Stack, Queue or List), since they reveal the intent of the structure. This terms get part of the Ubiquitous Language, if they are used outside the coders domain.
12. Use Problem Domain Names - simply use the Ubiquitous Language.
13. Add Meaningful Context - if you have a street and a city that is part of an address, make them elements of a class Address.
14. Don't Add Gratuitous Context - "Shorter names are generally better than longer ones, so long as they are clear. Add no more context to a name than is necessary." (p. 30)

...