In the old days, developers used all kinds of tricks to obscure the semantics of code; vowel collapsing, Hungarian notation, arbitrarily mixing upper and camel case, removing random letters. The special naming codes kept everybody in a job because special knowledge was needed to maintain software. But now programmers are unlikely to stay in the same company for ten years so consistency is important. Others need to be able to easily understand the source code.
Whilst a whole book could be written on naming conventions, this chapter has a few favorites mostly based around the following rule: English-like source code is easy to understand.
Only the most dedicated Propellerhead will miss code like this:
Dcmt dcRef = ths.rfSmr.pfnRgen(ths,usln,rvl);
compared to this..
Document doc = submissionManager.generateReport(this,
userSelections, defaultValues);
Tip: Use common sense, but longer words are usually better.
[name.convention] Follow conventions
[name.abbreviation] Accepted abbreviations are few
[name.constant] static final variables (constants)
[name.real] Use real names
[name.number] Keep numbers out of naming conventions
[name.magic] Ensure magic numbers have a name
[name.related] Relate variables through naming conventions
[name.goodest] Methods - Don't use Good Gooder Goodest
[name.acronym] Acronyms are words
[name.invent] Invent new acronyms once
[name.verbose] Longer variable and method names
[name.vowel] Vowels are cheap
[name.english] Use Plain English where possible
[name.context] Name attributes with respect to the class
[name.namespace] Consider namespace implications
[name.repeat] No need to repeat namespace information
[name.parameter] Naming parameters
