Every professional developer strives to implement good code. In this article, our Technical Manager, Vanesa Schimpf, shares some insights on how Clean Code can help you produce quality software.
Have you ever come across a bad code? Surely yes, and you probably felt impeded or delayed because of that bad code. Did it surprise you when you realized that you wrote that bad code? Don’t worry, it has happened to all of us.
As professional developers, sometimes, we are under pressure, running to finish what we promised in the time we promised. Maybe our boss will think we’re wasting our time if we delay our delivery by improving a solution that’s actually already working. We think that we will have time to improve it later, but that later never comes.
What we sometimes don’t realize is that this bad code impacts us in many ways. It decreases productivity by taking so long to understand it, it introduces errors by not being maintainable, each new change is more difficult and riskier by not being scalable, and even small requirements that should be easy and limited, end up being big changes that impact other places in the system. As the system grows with bad code, it becomes too complicated to continue working on it, and we begin to realize that we need to refactor it. Many refactors tend to be large, and it is sometimes tough to define the scope. We usually start by changing a small piece, but then we discover that it won’t be enough if we don’t improve the next part, so we end up with giant refactors that introduce a lot of bugs and generate a lot of re-work in all areas. At this point, there is not much more that we can do, and we end up with two possible situations: continue with infinite refactors or start with a new system in parallel with all that it implies (more resources, more time, more money).
We could avoid all those problems if we write good code! Yes, the responsibility is ours as programmers, and we have the power in our hands to define the result of what we create. It is easy to fall into bad code; however, as the authors, we can lead the experience that future readers will have when going through our code. Since we want to be good professionals, we must strive to produce quality software.
What is Clean Code?
The Clean Code term was used by Robert C. Martin in his book Clean Code: A Handbook of Agile Software Craftsmanship to describe a set of software design principles that help produce intuitive and maintainable code. Robert, or Uncle Bob, proposes a series of guides and good practices that every good programmer should follow in their nomenclatures and conventions.
In his book, you can find different interpretations of this term, where I can extract some interesting words: elegant code, easy to read and understand, efficient and performant, with minimal dependencies, with error handling, direct and focused on a single responsibility, with unit tests, and nothing obvious that can be improved.
Some of these guidelines and good practices are summarized below.
Main practices for writing good code
When creating new variables, it is very important to take the time to choose good names — those that make sense and leave no room for speculation or ambiguity. The name must be precise and self-explanatory of the intention and ultimate objective. It is also sensible to make them easily pronounceable so that they are easily grasped in our minds and can be referenced when discussing the code with someone else. Avoid variables with only one letter or that include the data type, very long or very similar names, or even too generic names that complicate the search and references.
These recommendations also apply to classes and methods, where we can add that they should be small and have a single responsibility. The classes must follow the concept of encapsulation and have their respective unit tests. Methods should have as few parameters as possible and avoid flag parameters as they would mean different methods. Look for 0 duplicity and 0 comments, greater reuse and expressive code, and functions without side effects.
Pay close attention to Code Smells!
The so-called Code Smells refer to suspicious code of being refactored. In other words, they are like flags that call our attention and invite us to look at it more closely, because perhaps it is necessary to improve it.
Among all the Code Smells, I can highlight:
- Function with many arguments
- Dead code, no one calls it
- Duplicated code
- Feature envy: too much usage of variables and functions from another class
- Magic numbers: Sometimes we see fixed numbers in the code that we don’t know where they came from, and they are not put into constants.
- Huge classes or functions that clearly don’t handle a single responsibility
- Negative conditionals, which are harder to understand
- Confusing or unintelligible names
- Reusing variables for different purposes
- Parameter overriding
- Many levels of nesting
- Lack of unit tests
If in these cases we carry out transformations that maintain the behavior, but at the same time change the internal structure so that it is easier to understand and modify, to correct possible bugs and simplify the logic, we will end up with a good code.
The last lines
As professional developers, it is our responsibility to implement good code. It is the mark we leave that shows us how we are as professionals, if we are committed to our work and seek excellence.
A sentence at the beginning of the book struck me: “Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.”
Undoubtedly, fixed delivery times, changes in requirements, resources with little experience (or a lack of them), different priorities in the team, unclear roles, lack of methodology, and coordination problems are everyday issues that threaten the code quality. Still, no one else is responsible for having good code other than ourselves, the developers.
Finally, I would like to close with the well-known analogy from the Boy Scout rule: Leave the code cleaner than you found it. Let’s not adhere to the typical excuse, it was already like this. Let’s make the code that we modify as if it were our own code. Let’s plan possible small refactors and the inclusion of the respective unit tests as part of our tasks.
For more information and details, I invite you to read Uncle Bob’s Clean Code book and thus, become better developers to leave good code wherever you go.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
