Why is clean code so important?
By DBLogic on 31/01/2018

As developers we always want to produce our very best work. For us, clean code is a matter of skill and expertise. We write our programs in such a way that the destination operating systems can execute our code efficiently. We know that at some point in the future, another programmer may have to read and comprehend what we've created.

However, there’s a lot more to writing clean code than just our professional pride.

Clean code performs better. The software we create not only needs to meet our customers’ requirements, but must also allow for project maintenance and extension. There are tried and tested methods for creating clean code that we adhere to, like consistent naming structures and rooting out duplication. However, the biggest adversary to keeping code clean is changing requirements.

While we aim to completely scope out each project, it is inevitable that additions and alterations will crop up. The agile methodology we use puts an emphasis on responding and adapting to altered requirements. Without having this structured approach, each alteration could make the code more complex and disjointed. (Less clean).

A series of small changes and fixes over time causes the entropy and technical debt to gradually increase. Entropy, when applied to coding, means that software can become increasingly complex if it is not actively worked against. Technical debt is a term used to describe the detrimental effect that an “easy” short term fix might have in the long term. We actively work to reduce both of these effects so that adding additional functionality and performing maintenance does not become a hugely time consuming task. 

So what happens if we need to work with code that has become overly complex and disorganised? The answer is that we use refactoring.

Refactoring is when we restructure existing code to make it cleaner and more efficient. By ensuring that refactoring is an integral part of our development process, we can keep the build-up of technical debt on a project to an acceptable level.

What is an “acceptable level”?

There are so many different factors to consider that there isn’t a single correct answer. Our key principle is that refactoring has to be of benefit to our clients. If it won’t deliver any added value then the extra time needed for refactoring could be difficult to justify. However, future additions and alterations may benefit a great deal from refactoring.  It’s a matter of balance and will be unique to each customer.

Creating clean code is an intrinsic part of what we do. Give us a call or drop us and email if you’d like to talk about how it can help your business.