What Is Clean Code 🔗 Naming Conventions — Part 1
What Is Clean Code
The thoughts and citations are coming from Clean Code book by Robert C. Martin. Based on answers of very well-known and experienced programmers, I have listed what clean code should have according to common idea:
Clean Code should:
- never obscures the designer’s intent
- look like it was written by someone who cares
- be elegant and efficient
- do one thing well(focused)
- have minimal dependencies to ease maintenance
- have unit and acceptance tests
These are important to know because trying to write clean code is meaningless if we don’t know what it means for code to be clean! Although programmers know that previous messes slow them down, most developers continue to make messes in order to meet deadlines and Bob Uncle tells us we will not make the deadline by making the mess and gives us advice to keep the code as clean as possible at all times.
Naming Conventions
There are many things to consider when we care about clean code but I will only mention about naming in this article, since it is the first challenge we face when we start coding and because we name our variables, our classes, our packages, everything.
1- Use Intention-Revealing Names:
The name of a variable should answer why it exist, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent and in addition to that, all magic numbers, single-letter names, noise words hide the intention of author.
2- Avoid Disinformation:
It is a nice practice to avoid abbreviations since they can mean something else we are not aware of. Also adding name of types to variable if they are not in that type would be disinformation. For instance, “refering to a grouping of accounts as an accountList unless it’s actually a List” is a disinformation. Again using single-letter names can be a disinformation. For example, the use of lower-case L or uppercase O as variable names can be understood wrongly since they are similar to one and zero.
3- Make Meaningful Distinctions:
Sometimes programmers names variables in an arbitrary way, because they can’t use the same name to refer to two different things in the same scope just to satisfy a compiler. There are three main types of mistakes, we developers often do:
- Misspelling variable: For instance naming a variable klass just because there is a variable named class.
- Using number series(a1, a2, .. aN): These variables actually are not disinformative but noninformative since they hide the intention of author.
- Noise words: These are the words that looks like different words but the meaning of them cannot be distinguished. For example using Customer, CustomerInfo, CustomerData in same codebase doesn’t make any sense to reader. As Bob Uncle says:
Distinguish names in such a way that the reader knows what the differences offer.
4- Use Pronounceable Names
Simply, if we cannot pronounce the names of variables, we cannot have easy conversations about code with teammates. Using single-letter names or abbreviations can cause unpronounceable code.
5- Use Searchable Names
Single-letter names, magic numbers have a particular problem in that they are not easy to locate across a body of text.​
The length of a name should correspond to the size of its scope.
6- Avoid Encodings​
Hungarian Notation and other forms of type encoding are simply impediments today, because when we change the type, we also have to change the name. They make the code also so noisier that we cannot easily read the meaningful part of the code. And they confuses the reader.
7- Interfaces and Implementations
The preceding I is a distraction at best and too much information at worst. “Robert C. Martin”
Leaving interfaces unadorned and changing the implementation hides the unnecessary information for readers like they don’t need to know they are handing an interface.
In Part 2, I will continue to write on naming conventions. Any feedback for improvement, problems will be much appreciated :) Hope to see you soon.
