Clean Code Chapter 2: Meaningful Names

If we need to talk about something that begins with that name. If something exists, it is identified by a name. Everything exists from names and gets mean with names. We use names to define everything in our software. Variables, functions, inputs, classes, pages, etc. Something so widely used deserves careful consideration. Let’s start and talk about Clean Code books’s second chapter: Meaningful Names

A scene about being understood correctly from a Turkish drama “Gibi”

First, I’d like to make a list of all the suggestions, and then I’ll go through each one individually.

• Use Intention-Revealing Names
• Avoid Disinformation
• Make Meaningful Distinctions
• Use Pronounceable Names
• Use Searchable Names
• Avoid Encodings
• Avoid Mental Mapping
• Don’t Be Cute
• Pick One Word per Concept
• Don’t Pun
• Use Solution Domain Names
• Use Problem Domain Names
• Add Meaningful Context
• Don’t Add Gratuitous Context

Use Intention-Revealing Names

Name must be clear and should give an idea about inventing-revealing. It’s not as easy as it sounds. “Choosing good names takes time but saves more than it takes. So take care with names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you use invention-revealing names. The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent”

I think we should find answers to the below questions.

Why does it exist?

What does it do?

Can Name be more clear?

Can Anyone understand?

Does the name serve a job?

Avoid Disinformation

Don’t use names to have different means or can be understood differently. Use words to give exact, strict means. Two Names from the book XYZControllerForEfficientHandlingOfStrings, XYZControllerForEfficientStorageOfStrings? Just one word is different, but it is so different to understand exactly why it exists. Don’t make it complex, work to make it easy.

Make Meaningful Distinctions

“Programmers create problems for themselves when they write code solely to satisfy a compiler or interpreter. For example, because you can’t use the same name to refer to two different things in the same scope, you might be tempted to change one name in an arbitrary way.”

When we don’t take care enough to name things, we give similar names to different things. But it’s not a practice. It’s critical to name helps to learn what code is doing. So that all names may serve a job.

“ Noise words are another meaningless distinction. 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. Info and Data are indistinct noise words like a, an, and the.” That is such a general case. So many times I saw info,data suffixes using different variables in the same class. “ Note that there is nothing wrong with using prefix conventions like a and the so long as they make a meaningful distinction. For example you might use a for all local variables and the for all function arguments. The problem comes in when you decide to call a variable theZork because you already have another variable named zork’’

There is an application we know of where this is illustrated. we’ve changed the names to protect the guilty, but here’s the exact form of the error:

getActiveAccount();

getActiveAccounts();

getActiveAccountInfo();

How are the programmers in this project supposed to know which of these functions to call. When the programmer looks at these methods will not understand the differences.

Use Pronounceable Names

“ If you can’t pronounce it, you can’t discuss it without sounding like an idiot. Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?” This matters because programming is a social activity “ “Fun or not, we were tolerating poor naming. New developers had to have the variables explained to them, and then they spoke about it in silly made-up words instead of using proper English terms. “ The brain ignores and passes on what cannot be defined and said.

Use Searchable Names

TDevelopers may need to look up existing names when performing an impact analysis or debugging a problem. For this reason, specialized and searchable names should be used.

Avoid Encodings

“It hardly seems reasonable to require each new employee to learn yet another encoding “language” in addition to learning the (usually considerable) body of code that they’ll be working in. It is an unnecessary mental burden when trying to solve a problem. Encoded names are seldom pronounceable and are easy to mis-type” Let’s say it over and over, don’t make it complex, keep it simple!

Avoid Mental Mapping

“This is a problem with single-letter variable names. Certainly, a loop counter may be named i or j or k (though never l!) if its scope is very small and no other names can conflict with it. In general, programmers are pretty smart people. Smart people sometimes like to show off their smarts by demonstrating their mental juggling abilities.

One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand”

Class Names

“Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be a verb.”

Method Names

“Methods should have verb or verb phrase names like postPayment, deletePage, or save. Accessors, mutators, and predicates should be named for their value and prefixed with get, set, and is according to the JavaBean standard.When constructors are overloaded, use static factory methods with names that describe the arguments. For example,

Complex fulcrumPoint = Complex.FromRealNumber(23.0); is generally better than

Complex fulcrumPoint = new Complex(23.0);”

Don’t Be Cute

Say what you mean. Mean what you say

Pick One Word per Concept

Don’t Pun

“Our goal, as authors, is to make our code as easy as possible to understand. We want our code to be a quick skim, not an intense study. We want to use the popular paperback model whereby the author is responsible for making himself clear and not the academic model where it is the scholar’s job to dig the meaning out of the paper”

Use Solution Domain Names

“Remember that the people who read your code will be programmers. So go ahead and use computer science (CS) terms, algorithm names, pattern names, math terms, and so forth. It is not wise to draw every name from the problem domain because we don’t want our coworkers to have to run back and forth to the customer asking what every name means when they already know the concept by a different name. Choosing technical names for those things is usually the most appropriate course”

Use Problem Domain Names

“When there is no “programmer-eese” for what you’re doing, use the name from the problem domain. At least the programmer who maintains your code can ask a domain expert what it means. Separating solution and problem domain concepts is part of the job of a good programmer and designer. The code that has more to do with problem domain concepts should have names drawn from the problem domain”