Hello, folks!
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. To prove it, I have 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 have 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 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 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 when starting a new 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 to 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 it this way for now and I come back to fix it later” is a free ticket 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 as a cement block which has just been put wrongly on the ground: take the chance to fix it while it’s still wet, because, 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 practising 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, consider that you have just moved to a new house and you are 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 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 time, expensive. Furthermore, you will not be able to assure that it’ll have the same behaviour as before, unless you run effective unit tests.
We must have a commitment to 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
By 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 looking upon better alternatives to deal with the business logic are examples of a great technical sensibility. The higher 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 the next day. As a matter of fact, it will probably 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 developers’ shoes and find the difficulties that they 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 practising Clean Code. That’s all for now!
I would like to thank you all for visiting my blog and also for taking the time to read this article.
Whenever possible, I’ll post more articles in English, ok?
Bye!