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!