What is clean code

Alok Simha, Principal Developer, Geektrust

As a part of what we do at Geektrust, we give developers feedback on their solutions to our coding challenges. Naturally, we end up repeating the same feedback a lot because the basis of differentiating good code vs bad is the same. Sure, we factor in styles and preferences but the core aspects remain the same. This post will help future code submitters understand in depth what we look for in code. So here goes!

Let’s say you’ve developed a piece of software for XYZ company. You no longer work for XYZ. There is an important bug fix that needs to be done and a new person is assigned to the task of fixing it. He/She cannot draw his/her own interpretation of how the software is written and executed. A piece of code a computer can understand has to be predictable, given that it follows a programmed set of logic and conditions. It becomes very important for the person who is maintaining your software to understand and fix bugs or add additional features in the shortest amount of time possible.

What constitutes good code is subjective – what I consider good code might not be good for another developer.

However, sometimes we look at a piece of code we wrote 6 months ago and go, “did I really write this? Why would I write something like this?” To avoid such situations there has to be some basic set of principles to define good code.

1) It works!

The most important aspect of good code is that it works. Irrespective of how beautiful you think your code is, if it does not work or cannot be deployed to production then it is not good code. This also means it is performant. The execution of a piece of logic cannot take forever to determine a result. Good code that works is like an old car that still keeps running with very little maintenance bills every year.

2) Reusable

Good code means there are components that can be reused. If there is duplicate code across functions/classes it might be a good practice to pull them out into a common util or a behaviour to a class that can be called from multiple places. How would this help, you may ask. If there is a bug fix it would be better to do it in one place instead of fixing it in multiple places and missing out on some because of duplicated code. Also, it makes it easier for someone to read smaller readable functions which have a single responsibility.

3) Expressive

Good code should be able to express themselves. Just like a human emotion, by looking at the expression of the person we should be able to know if he/she is happy or sad or angry.

Good code follows a good set of naming conventions. Naming of variables should have a consistent pattern. How often do we come across variables like i, i1 etc. and wonder what they mean? Long functions are too difficult to read. They could be broken down into smaller meaningful functions with descriptive function names. A good practice would be to limit a function so that they can be read quickly. And limit your functions to no longer than a single screen height, so you don’t keep scrolling to understand what it’s doing.

4) Modular

Just like how we design our houses and office spaces, our code should be modular. A kitchen should have all the cutting tools and accessories that it needs. If you were to chop vegetables it is assumed you’ll find the necessary items in the kitchen and be able to do the chopping in the kitchen and not in the bedroom, correct? Similarly, when we look at code we should be able to categorize a piece of code as View layer, Model layer, Service layer, DB related code and so on. Even within a single module, it’s a good practice to group related code in a package/directory. When there is a bug fix, you’ll know where it should be if your code is organized well.

At the end of the day, if your code can be understood and defined by a completely new person on your team the same way you would, then you’ve done a good job of writing good code.

Every time you take decisions — should I name it this way, should I create a new class or should I break this function into smaller functions — it’ll be good to pause for a second and think whether someone else will understand it.