What the f*** is clean code?

“Even bad code can function”. This quote comes from a book written by famous American engineer — Robert Cecil Martin, Clean Code. Some of you may know him as Uncle Bob. In his book, he goes on to explain a few practices which help produce code that is simple, maintainable, and flexible. Written in 2008 a lot has changed in technology since then and these few principles remain the same. But what does clean code look like to you? Having worked as a Software Engineer for some time now here is what I’ve learned.

There is no straight answer here with many definitions of what clean code is to a variety of developers. Clean code can also be subjective to the type of programming style you use. But essentially clean code boils down to this one simple rule. It’s easy to understand and also easy to change.

Here are a few very common software engineering principles and ones I’ve stumbled upon by trial and error that have helped me create cleaner code.

DRY/DIE

Don’t repeat yourself or duplication is evil. A bit extreme but for good reason. Let’s look at an example below.

We have three different functions for generating car types. We need to call each function for each of these car types. To avoid code duplication and in doing so reducing technical debt, we can instead do something like this.

We now only have one function which we can reuse by passing in the required parameter. Way better right?

Kiss

Keep it super simple or keep it simple stupid. This one speaks for itself. As engineers, we often find ourselves in situations where we’ve over-cooked code. This is one of the main reasons behind a lot of technical debt in legacy systems. Let’s look at another example.

Single responsibility rule with a dash of less is more. In the example below we can see that we’re checking whether the bin is empty so we can refill it. We have two variables isBinEmpty and canRefill. If the bin is empty, we set canRefill to true and isBinEmpty to false, then we log the results. 🤔

We can simplify this by removing the canRefill variable, relying on just isBinEmpty. We can also apply the single responsibility rule by ensuring that the logging logic only does logging. The result is as shown below, from 9 lines of code to 2. Easy.

Naming is everything

If you’ve been programming for a while now you know how important this one is. Naming aids understanding and if the code you’re working with is old, good naming is your best friend. Sometimes it is often better to group logic into its own variable rather than having it spread out as separate operations. I will show you what I mean in the following example.

We have a function that takes in two booleans that performs the AND operation with each other. The result shows us whether the shape is a square. Given these two properties in the example shown below, we expect to see that it is indeed a square.

However, this logic can be improved and broken down even further into two single lines. Not only is it much easier to understand, but we have also refactored the code to be nothing more than what it needs to be by assigning the two parameters with an AND operator connecting them.

Do I even need this anymore

If I had a dollar for every time I asked this question, well I’d be rich. You’ll need to constantly ask yourself this, again, and again. This is one of those things that you should do as programming diligence, like writing unit tests and making sure you’ve tested your code to see that it works.

Continuing on from the example above, we can refactor this piece even more. We ask ourselves, do we even need the isSquare variable anymore? No, we don’t and we can just return the result instead.

Clean code doesn’t necessarily stop at writing “clean” code. It is made in a collaborative environment with consistent communication within your team. It is continuously thinking about the past, present, and future from different perspectives and always questioning everything. It’s a way of </life>.