In software development, source code is the core element. It contains all features of the software, its logic but also all its bugs. Developers work with code on a daily basis: they are led to modify it but above all, understand it.
A developer usually spends more time reading code than writing code. That explains why the more legible the code is, the more value it has. And practically speaking, that is true: modifying the code (bug, feature addition) is less expensive if the code base is easily understandable. Also, it makes a new arrival in the project team easier and other team members are usually more satisfied to work with a pleasant code.
Although there is no defined rule to produce clean code, because every developer has its own opinion on the topic, the community seems to have spotted several good practices to observe. To mention but a few, my choices would be writing unit tests, having peer developers review your code and using tools to monitor the quality of your code. But the most important is that each developer gets involved, pays attention to the code and takes responsibility of it. Those good practices are gathered under the name of Clean Code and I can only but recommend developers to read Clean Code: A Handbook of Agile Software Craftsmanship from Robert C. Martin (if you haven’t read it yet), which is a classic, and the only book I’ve read more than once.
To conclude, it’s really important to consider this clean code notion, to talk about it and to implement rules in each project to move towards a cleaner code base. It’s a meticulous work, from many small decisions, which, on the duration of a project, can make the difference.
