Clean Code Chapter 2: How to choose Meaningful Names

“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

My opinion that this Chapter is the Core of this Book, everything starts by naming.

The book states that if a name requires a comment, then the name does not reveal it’s intent.

We should use names that clearly specify the intent of what it does, how to use and why it exists.

Some more detailed concepts from the chapter:

• Avoid words whose meaning vary from the intended meaning. Example, do not refer to a group of accounts as an accountList unless it’s actually using a List
• We shouldn’t use the wrong abbreviation, like hp, aix, and sco (names of Unix plat- forms or variant )
• A truly awful example of disinformative names would be the use of lower-case L or uppercase O as variable names, especially in combination. The problem, of course, is that they look almost entirely like the constants one and zero
• Avoid Noise words and meaningless distinctions. Imagine that you have a Product class. If you have another called ProductInfo or ProductData, you have made the names different without making them mean anything different.
• Avoid being redundant. How is nameString better than name? moneyAmount is indistinguishable from money.
• We should use naming that it’s easy to pronounce.
• We shouldn’t use single characters in variable naming “e, z, 8”
• We can use kAMEL form
• Avoid Mental Mapping, It’s recommended to use I or j or k for the loop instead of a and b.
• Classes and objects should have noun or phrase nouns. It should not be a verb.
• Methods should have verb or verb phrase names like postPayment, deletePage, or save.
• Use Solution Domain Names, We should remember that the code will be used by programmers so we should use technical names.
• we should be smart, not too long and not too short, Too short: reduces meaning, Too Long: hard to pronounce and talk about.