Chapter 30. Get Better at Naming Things
Peter Hilton
What is above all needed is to let the meaning choose the word, and not the other way around…the worst thing one can do with words is surrender to them.
George Orwell
Getting better at naming things improves the maintainability of the code you write more than anything else. There’s more to maintainable code than good naming, but naming things is famously hard, and usually neglected. Fortunately, programmers like a challenge.
First, avoid names that are meaningless (foo) or too abstract (data), duplicated (data2) or vague (DataManager), abbreviated or short (dat). Single letters (d) are the worst of all. These names are ambiguous, which slows everyone down because programmers spend more time reading code than writing code.
Next, adopt guidelines for better names—words with precise meanings that make the code say what it means.
Use up to four words for each name, and don’t use abbreviations (except for id and those you adopt from the problem domain). One word is rarely enough; using more than four is clumsy and stops adding meaning. Java programmers use long class names but often prefer short local variable names, even when they’re worse.
Learn and use problem domain terminology—domain-driven design’s ubiquitous vocabulary. This is often concise: in publishing, the correct term for text changes might be revision or edit, depending ...