Clean Code: YES, PLEASE!

Eight tips to get a quality code.

If it is not clean code, it is a botched job. And this is something categorical. A messy code can make you solve deliveries and even earn money, but it does not stop it from being a shoddy job.

Puedes ️leer este artículo también en Español por Ivan Coronado.

As a developer, I’ve noticed for a long time that there is a little culture of making quality code, both on the part of companies and on the part of programmers. In fact, I would dare to say that in most cases neither companies nor customers would know if the code is good or bad. Why? Well, almost everybody has always followed a short-term strategy. This strategy has focused on adding new features no matter how. And of course, if nobody claims clean code, it is easier to pass by and not worry about it.

But the truth is that worrying about the quality of our code benefits us all: companies, programmers, and customers.

Why does clean code benefit the company?

• In the long run clean code comes out cheaper: Don’t forget that with a poor quality code you will spend more money to fix a bug and it will be more difficult to add new functionalities when the project grows.
• It prevents the flight of talent: It is a fact that good programmers do not want to work on projects that are a disaster at the code level.
• It reduces dependence on programmers: It will be ok if someone with a vast knowledge of the project leaves, finding a substitute will always be much easier if the code is clean and coherent.

Behind every “this project would be better to start it again” there is a company losing money.

Why does clean code benefit the programmer?

• It reduces frustration and stress, which translates into an increase in happiness and personal satisfaction.
• It also reduces the time invested in detecting the cause of errors, thus gaining time to keep the code clean and assimilate knowledge (let’s say that the clean code feeds back).
• It helps you grow as a professional, even allowing you to choose where you want to work.

Never forget that a good programmer works where he wants, while a bad one works where they let him.

Why does a clean code benefit customers?

• It increases performance and decreases errors, which translates into a better experience for users.
• It is more reusable and scalable, which allows adding new features or making changes to existing ones easier and therefore cheaper in the long term.
• It survives trends better: If a new technology or a new framework comes out, it will always be easier for you to migrate on a reliable basis.

When hiring a product, make sure you are not being cheated and what you receive meets the minimum quality standards.

I’ve been chasing code more readable, scalable and reusable for a long time, and it’s something essential for us in Commite Inc., where we work every day to make the clean code our mantra.

How do we do it? These eight tips will help you get an idea:

- All in one

The first thing is that both for the company and for the programmers the clean code must be a prime objective. It’s no use that the programmers work very hard to make a clean code if the company presses deliveries and doesn’t provide with appropriate tools. The same thing happens in the opposite direction: if the company offers training and flexibility but the programmers do not show interest, the battle is equally lost.

- Read the sacred book

Every doctrine has its holy text, and in this case, it is called Clean Code . Any self-respecting programmer should read and assimilate the book, regardless of the technology that they use. Stop chopping code and start programming.

- Version control

Use a version control tool, and by that I mean GIT version control tool: It is free software, it is the standard, and there are so many tools working already on it that it will help us to make our code better.

- Follow a code style guide

If we had to write a book among several people, we would not think of writing each one with different typography, font size or line spacing in the same document, right? So why do we do it when we write code? Before starting any project, we should have a code style guide for each technology that we will use. It is not necessary to choose a new one each time, not even to do it ourselves. Just look on the Internet “style guide {{desired technology}}” and make sure everyone follows it. A more uniform code will allow everyone to adapt better to the project and to think less to interpret it.
It’s advisable to be integrated into the IDE to notify us when we are not complying or even correct the errors for us. We are in the 21st century, let’s begin to act as such by delegating repetitive tasks to machines.

- Plan

Use an agile methodology, but not as an excuse to not plan. The project should have a roadmap that all the team should know. It does not need to be ultra detailed, just an approximation. Go drifting away is not positive for any project.

Use SCRUM and the “blessed” sprints, or a simple KANBAN board, which best suits your project. As a programmer I prefer the latter, it works more relaxed, and I think it favors better code quality. The sprints put too much pressure on the team and sometimes they are counterproductive, although I understand that for those who manage the project they are a useful tool.

- Check the code

Engrave the following statement in your brain:

No one should add code to the project without being reviewed by at least one other member of the team.

If you’re doing it, which I’m almost sure of, you’ll hardly be doing clean code. Every company should have a senior figure in {{insert technology or framework}} that reviews what is added to the project to prevent people from following anti-patterns.

Some of the advantages of the code review are that it allows detecting errors, transmitting knowledge among team members and helping everyone to be aware of the changes in the code. This is the only way to get a clean code when more than one person is working on the same project.

- Divide and win

Divide the work into tasks of a maximum duration of 4 hours, extensive assignments give a feeling of not advancing and discourage the team. Without counting that, as we have agreed before, someone will have to revise that code. If the tasks do too many things, it is impossible to do a good review.
(Notice to managers: Try adding a concise description of what you should do and a TO-DO list with the requirements that must be met)
(Warning for programmers: Before you start doing anything, make sure you understand what you have to do; otherwise it is difficult for your solution to be optimal).

- Control technical debt

It is inevitable to accumulate technical debt in a project, but this should be controlled. So when you are introducing something that you know it could have been done better, create immediately a task explaining how it could be improved (take advantage of the fact that you have it fresh).

In case someone does not understand it, at some point you have to invest time in reducing technical debt. The ideal would be to reserve X time per week or to stop a week at some point to solve this purpose.

I believe that these are the bases to get to make a code of higher quality. If we miss any point, we will hardly achieve it. For those who struggle in their day to day for this goal, I expect your comments on what works best for you. For those who do not, I hope, at least, to have awakened your curiosity on the subject.

Happy coding!