Clean Code and Meaningful Names in Programming

In this article I’m going to talk about the chapters 1 and 2 from Robert Martin’s Clean Code book. We are going to take a deep dive into what is clean code and some of the things in covers. Additionally, we will start with clean code practices for naming variables, classes, methods, etc.

We humans will always produce code, not machines or automatic code.

Many people believe that in the future this will be done automatically, the truth is that is almost impossible for this to happen because the requirements need to be very specific, even us humans with all our creativity and comprehension skills have a hard time programming and defining this requirements

“Bad code is very punishing and can shut down companies” — Kent Beck

Several times in programming history, the event of a company shutting down because the code is a huge mess, has happened. There are multiple examples of an amazing app or product the made a huge impact on the market, making it very useful and demanding by everyone, and in this process of keeping everyone happy and making new updates, the code started to crumble and became harder and harder to maintain. Until it reached a point in which the product or app was no useful anymore because of all the bugs.

Wading

This is used to describe a code that is so bad that it impedes the programmer of maintaining it, adding features to it, or fixing bugs. You simply don’t know what you are reading or programming.

LeBlanc law: “Later equals never”

Many times when we produce code, we want to finish fast or complete a certain due date. And many things we write them incorrectly or not in the best way possible because we want to make it work first and then refactor. The truth is that this process will never occur.

We programmers should protect the code. Its better clean code than due time

Many times we get pushed by our managers to complete a certain due date or that we need to deliver a new version for the client in a hurry. But the truth is that we should always prioritize clean code first. We are the programmers and we know that to make bad code in order to complete the due date is a big mistake for the future, even if the client gets mad, we need to prioritize clean code. Take for instance the example of a doctor when he or she is preparing to make a surgery. If a patient tells them to hurry up and skip the part of washing their hands and start the surgery, the doctor will not obey the patient even though the patient is the client, the doctor knows better and ignores that request for the sake of the patients life. This applies to clean code.

Not because you identify bad code means that you can do good code

Many people can identify bad code, but making good code is not something easy to know or do. It takes times, practice and knowledge of what to do and how. And not because you know something is not right, it means that you know how to do it correctly.

“Clean code is pleasing to read” — Bjarne Stroustrup

Clean code should be easy to read, easy to change, easy to maintain by a developer other than its original author. Its minimal and efficient. We need to care for code and realize that when you are reading it.

Beck’s rules of simple code

• Runs all the tests;

• Contains no duplication;

• Expresses all the design ideas that are in the system;

• Minimizes the number of entities such as classes, methods, functions, and the like.

“You can call it beautiful code when the code also makes it look like the language was made for the problem” — Ward Cunningham

This phrase says it all, when you apply clean code you can sense that things match together so perfectly that everything makes sense and is very easy to read and understand.

We are all authors and have readers, when we code we have to think about our readers and what they will read.

When a writer is creating a novel, he or she puts himself at the other end and wants their readers to feel good, that they understand everything and that they can even imagine pictures and sounds with the words they are reading, a novelist takes care of his or her readers because they want to make them feel comfortable when reading his words. The same thing should apply to our code, we don’t know who is going to read it in the future but we want them to hace a good time reading it.

Apply boy scouts rule in code, leave the campground cleaner than you found it.

When we are programming we should always look for ways to make the code cleaner, even if that part of the code is not ours or in the feature we are doing or fixing. We are all a team and should help each other out. So if you are navigating and see something that can be cleaner, modify it. And slowly the code will become so clean than anyone that attacks it will hace a good time understanding everything.

We have to name correctly everything

When we say everything, we mean everything. It includes variables, methods, classes, modules, files, projects, etc.

If a name requires a comment, then the name does not reveal its intent.

We need to be very precise and explicit when naming anything. By reading a variable or class we should know what it is o what it is doing.

Name the variables by what they are, avoid abbreviations that are misinformative

We want to literally name something by what it is or what it does, be direct and explicit on it. Also, do not abbreviate because this can confuse or have programmers guessing what this abbreviation is.

Use pronounceable variable names

We are going to be discussing our code with other people and we don’t to be sounding all weird or goofy when pronouncing variables with really weird or unpronounceable names. So in order to avoid this awkward moments use pronounceable variable names.

Don’t use one letter variables because they are difficult to search

When searching for a variable we want to make them easy to find. When you name a one letter variable, you will have a hard time finding them when using the find tool. Also. lower case L and upper case O as variable names is really bad because it can get mixed with the number 0 and 1, so a little heads on that too, avoid one letter variables.

Don’t use prefixes in variables, at the end they will be ignored by the reader

At the end of the day, the prefix will be ignored by the reader because that they really want to know is the name of the variable that describes it, so avoid this useless prefixes.

Clarity is king, that’s the difference between a smart programmer and a professional programmer

Generally programmer are smart and they can remember what a certain weird variable is, even though the name is non-explicit or makes no sense at all. But we are not looking for this, because it breaks the process of passing the code to someone else. A professional programmer doesn’t show off in this manner because he or she knows that this is not good for the code’s scalability and maintenance.

Quick tips for naming

• Class names should be nouns, not verbs
• Methods should be verbs

Say what you mean. Mean what you say.

Don’t name variables with slangs or jokes that only certain people know. Because not everyone will understand this names and it will get confusing in the long run when the people that get the jokes and slang have left.

Use one word per concept

For example avoid using get, retrieve, fetch for methods that do the same thing. This will give the readers a hard time in trying to figure out what’s the difference between these methods and which should they call.

Avoid using the same word for two purposes

When duplicating names you will encounter several scenarios in which you will not know easily which variable you are referring to. Even if they are pretty similar they should be named very different.

Use technical names so that programmers can easily understand what a certain thing does

We as programmers know a los of technical names and processes. We should keep using this terms for our code to be easier to identify and read. Even if the customer doesn’t understand a certain variable or class name, for the people that will maintain it, it will make perfect sense and even help them understand things easier.

The end

I hope you find this article helpful in some clean code practices and what clean code means and what it’s objective is. I really recommend the Clean Code book by Robert Martin where you will find a lot of more practices of clean code. As always any doubt feel free to contact me!