Programming in a clear and comprehensive way is crucial for any software development firm. But the slightly overused term of clean code suffers from a serious vulnerability — the human being behind the screen.

Ever since Robert C. Martin published his extensive book on how to write code properly, various approaches towards so-called clean code have emerged. It is now overused to such an extent that we can easily label the entire term a buzzword.

According to various professionals, clean coders should aim to write code that is easy for anyone to understand. But what exactly does it mean? Is there a standardized approach? Do we have a set of rules to avoid possible miscommunication?

I believe that clean code mainly reflects what you and your colleagues are comfortable working with. And while everyone has a different history and experience, the whole concept turns out to be super subjective.

That is why I have decided to put the term under scrutiny, determine its component parts, and identify its benefits.

Empathy is way more important than skill

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” said an iconic British software developer Martin Fowler and there is a good deal of truth in his statement.

Let’s take a look at this example. The code below monitors how much time remains until it is necessary to recheck if a certain subscription is about to expire. It takes two numbers msSinceBought and duration, divides them and rounds the result.

The code below does pretty much the same thing with the identical purpose. The difference lies in the way they operate under the surface.

The first example relies on autoboxing: converting result (in this case a number) to a string and parsing a number out of that string. While the second code only uses numbers and rounds them (via Math.floor).

Computers don’t mind using any of these examples and both work properly. The problem with implementing such code is elsewhere. It is, in fact...

Unlike computers, people tend to have their own code designs they prefer. That is why I have realized that more than some sort of a guidebook, the concept of clean code reflects a changeable consensus.

I have identified two characteristics we have to acquire to write what we call clean code. We need both skill and empathy, with the latter playing a more significant role.

The reason why empathy is more important than skill is that, over time, skill is derived from empathy. In order to write code, we have to read the work of others, and we have to read about code, which is basically a distillation of what other people like. It definitely doesn’t go the other way round since there simply isn’t any clear list of rules set in stone.

Keep it SOLID, stupid

Despite being very subjective, clean code still remains a challenge that many programmers embrace. Over the years, many concepts have emerged to give developers at least a basic path to follow when writing code.

Dating to the early days of Unix hackers, the KISS and DRY principles have influenced a few generations already. They both send a clear and rather self-explanatory message.

Keep It Simple, Stupid (or KISS for short) emphasizes the need to avoid unnecessary complexity or premature optimizations. Don’t Repeat Yourself, or DRY, means we should avoid writing the same code in multiple places that we will have to keep synchronized every time it changes.

Slightly younger yet a bit more widely adopted is the SOLID principle, which consists of five sub-principles. The first of them stands for Single Responsibility, which underlines the need to establish only one role for each of the classes (or modules, units of code, functions, etc.). However that definition can seem a bit vague itself.

It appears to me that it communicates the idea less clearly that the original KISS and DRY rules. Single responsibility feels a bit vague because no one really knows what the real responsibility is. We can get the notion of what it might be after working with the code. But in general, it means “the code is doing way too much, I’m losing track. I don’t know what it is doing, so let’s just break it down.”

The Liskov Substitution principle (SOLID’s letter L) assumes that we have a set of elements and certain invariants hold for the set. Then we get a subclass where the same invariants should hold. This can be illustrated using categories like Fighter and its more specialized subclass, Professional Fighter. According to the Liskov Substitution principle, if you have a piece of code that works for Fighter, it should work for Professional Fighter as well.

The very last letter of SOLID stands for the Dependency Injection principle, suggesting that high-level modules should not depend on low-level ones, only on their abstractions. Basically, it means that if you want a banana, you don’t want the gorilla holding it or the forest the gorilla lives in.

All of these make sense, but I personally haven't found much application for the last two principles: Open/Closed and Interface Segregation. I suspect that the creator of the acronym included them to add some vowels because SLD is a lot less catchy.

High-quality code drives motivation

Even though the clean code concept lacks any universally accepted meaning, there still are exceptions that prove the rule useful. The term offers a few overlooked benefits. If nothing else, it forces us to think: what is the reason we even search for clean code? Or, to make it a bit less buzzwordy, why do we strive for code we like?

One of the main reasons why we should not cease to look for clean code is its effect on team morale. Developers in general hate maintaining bad code or code they don’t feel comfortable with. In such situations, they can even start to dislike their work and look for other options in the marketplace.

On the other hand, keeping the code in good shape can make the team working with it proud of their work, which could also increase their productivity.

The role of code quality in the workplace was described in Tom DeMarco’s book Peopleware: Productive Projects and Teams. Even though the book was published in 1987, the message remains clear to the present day: do not underestimate the importance of code quality if you want your employees and colleagues to be content and productive.

Productivity is a major element that can be influenced by aspiring for clean code. Approaching projects with a long-term outlook can save time and energy at the end of the day.

One of the major false dilemmas I have encountered at Salsita was whether we should resort to quick fixes or improve code bases more slowly and thoroughly.

I have found that going with the fast and easy approach is the road to hell in the long run. The mess produced by each fix just accumulates and in the end, it turns out to be counterproductive.

Breaking things into modules brings both profit and suffering

Another example where it pays to strive for clean code is modularity: breaking things down into separate modules with clean interfaces between them.

In 99 percent of cases, modularity is a great way to save energy. It helps you minimize your mental load, as well as limit the scope you operate within. It makes the code more flexible and even enables code reuse.

However, there is always a catch, and modularity can become a nuisance. For instance, as Fred Brooks wrote in his book The Mythical Man-Month, writing reusable components can take up twice as much time as the ordinary one. Also, the more components you have, the more complex it becomes with a need for more interfaces, more dependencies, and more interaction.

Few things to remember

Whatever your project is about, always bear in mind a couple of rules. Firstly, everything is about context so always evaluate the purpose of the code you are working on and make sure the time you spend on code quality is really worth it. Secondly, to maintain a great working environment with high levels of productivity, always discuss your code and its use and come up with your own consensus as a team on how to keep your code clean.