In December of 2013, I started reading a book called “Clean Code” written by Robert C. Martin and I have to say that I’ve learned lots, lots of things from it. Previously, in the ninth part of tips for developing software, I already mentioned a short paragraph about Clean Code, as well as I’ve also been writing some recent articles about this topic (in Portuguese). Today, I’ll go a little bit further on this set of practices and give some orientations on how to use it. Clean your code now!
Before I start off, I’d like to state that this is my first article written in English, so, in advance, I apologize for my grammar mistakes and any incoherence.
All of us, developers, have the desire to see our code working in the best possible structure, right? When I say “working”, I’m not referring only to the correct execution, but also to the code quality and expressivity level that it reveals. After all, when we code a solution, the result will be seen by our users AND by ourselves.
I believe that you’ve already come across an old code and spent several minutes (or maybe a few hours) trying to understand what it does. Likewise, I also believe that you’ve rewritten blocks of code due to the absence of clarity. Am I right?
The concept of Clean Code was elaborated just to avoid the code illegibility and improve the technical quality of our implementation. Clean Code provides a set of instructions that should be adopted by any developer who wants to be recognized as a good professional. However, unlike many people think, just reading the book is not enough to take knowledge of all Clean Code guidelines. The developer needs time, practice and, above all, perseverance to produce an intelligible code. For this purpose, I decided to gather some points approached in the book and share them in this article in order to disseminate the basics of this concept. Read them carefully and remember them when you write your next code.
1) It’s unlikely to write a clean code since the beginning of an implementation
Even if you try, it’s practically impossible. Although it’s extremely important that a developer begins an implementation using the directives of Clean Code in mind, he will eventually return to the code to refactor or rename some methods and variables which are liable of bad interpretation. Yet, this is perfectly natural. When we begin a new implementation, we don’t know exactly how many methods will be necessary. We don’t know how to name and declare them too. So, there is nothing to clean. It’s only when the code takes shape that we start to find the “dirty spots”.
2) Stop coding when you notice that the code is bad
Avoid writing all the code and only clean it afterwards. The cleaning must be done gradually, otherwise, it’s pretty likely that the developer will lose the context of the code as a whole. That usual idea of “I’m going to let this way for now and I come back to fix it later” is a free passage to forgetfulness. Therefore, when you notice that the code is taking inadequate proportions and exposing signs of duplication, stop writing and perform a cleaning before moving on. This is the same situation of a cement block which has just been put wrongly on the ground: take the chance to fix it while it’s still wet. If it dries, the work of replacing or reforming it will be undoubtedly tougher.
3) Learn to code with patience
One of the effects of practicing Clean Code is the constant activity of removing and adding the same code over and over again. It’s part of the maturity process to achieve the ideal level of quality. I can’t even remember the number of times that I had to create, modify, remove, create again and rename a class. At each step, I came up with a different perspective of the code and modified it to make it more understandable.
As an analogy, imagine that you have just moved to a new house and you’re arranging the furniture of the main room to find out the most comfortable accommodation. You’ll probably need to change the location of the furniture several times, right? That’s the point! Just like you look for the best disposition of your furniture, you also have to look for the best structure of your code. Still about the analogy, one more similarity: the same way people will pay a visit to your house, other developers will also “pay a visit” to your code!
What I mean is, if you wish to create a clean and valuable code, be ready to undo and redo blocks of code as many times as necessary.
4) Consider programming as a high risk activity
If a functional requirement is not documented, it’s relatively simple to fix the documentation. If there’s a mistake in estimation, the schedule and user stories can be adjusted with the P.O. However, if a code is written badly, rewriting it is something slow and, most of the times, expensive. Furthermore, you won’t be able to assure that it’ll have the same behavior as before, unless you run effective unit tests.
We must have a commitment with the relevance of our code, considering that the result of the implementation (and, consequently, the feature) is inwardly related to our level of responsibility. And, hey, we want to be responsible!
To make it clear, the purpose of this topic is not to put the developer’s conscience under pressure or punish him for writing an imperfect code, but to suggest that he considers the importance of his activity when it comes to the project’s quality, sustainable architecture, collaboration and, of course, the project’s lifecycle.
5) Improve your sensibility to the code
As using Clean Code practices, the developer builds and develops an ability called “sensibility to the code”. This term refers to the capacity of reading a bad code and immediately think of different ways to clean it. Renaming variables, rewriting nested code, refining conditions, extracting methods and even look upon better alternatives to deal with the business logic are examples of a great technical sensibility. The higher is this level of sensibility, the better will be the solutions designed and written by the developer. SOLID principles and Design Patterns are included here!
6) Write your code thinking in readability
A good recommendation on how to practice Clean Code is to write the code already thinking that someone else will read it in the next day. As a matter of fact, it will happen! So, make sure you read each method right after writing it and try to measure the level of readability. Try to put yourself in other developer’s shoes and find the difficulties that he could have when reading your code. Although it seems to be a tiresome task, it’s actually rewarding, as you get to know the quality of your own code to do something better next time.
Well, I hope to have conveyed the basics of practicing Clean Code. That’s all for now!
I’d like to thank you all for visiting my blog and also for taking your time to read this article.
Whenever possible, I’ll post other articles in English, ok?