What is Clean Code And How We Can Achieve It?

While there is a lot of BS around Clean Code – I feel Perfect Clean Code is impossible to achieve given the constraints of time and budget any team has.

The Perfect Clean Code concept is a utopia akin to the pursuit of any perfection like the perfect date, a perfect life, a perfect job and so on- Attractive but not 100% possible.

That being said, it is really important to work towards it as well.

Hence I thought of writing this blog to outline what is clean code programming and its practical clean code principles that would solve over 80% of your problems and you can really have them implemented by your team.

What Is Clean Code?

Simply put- clean code means simple, understandable code that is efficient, reasonably free of bugs and maintainable.

Easy to read- It’s a no-brainer
The code needs to be small and clear. It should not have unnecessary aspects. Also, There are many ways to shrink your code but that is not necessarily the way to more clear code. Ternary operators and lambda expressions are big culprits of this.

Use meaningful names throughout the code
Use meaningful names in your variables, classes, and functions. Just having a proper method name often saves me the trouble of even looking up the docs for what it does. Functions should be verbs – This goes without saying but this makes the code read more like a story.

Variables should be nouns. Pronounceable variable and function names – so instead of temp write out the word temporary or temperature. Instead, qtyOH writes it out to quantityOnHand. Descriptive variable and function names – The less mental mapping that a programmer has to do when reading your code the faster he can fix that.

If the declared variable name needs a comment or description, like what is the use of it, then it is advisable to change it immediately and make it self-descriptive. 

Example of a Bad Variable Name

Date cd; // created date of the record

Example of a Good Variable Name

Date createdDate;
Date createdAt;

Every declared variable should be able to be pronounced easily.

Example of a Bad Variable 

Date yyyyMMdd = "2022/03/31"

Example of a Good Variable

Date createdDate = "2022/03/31"

Focussed class or function
When you realize your class or function is going out of bounds of what you first meant it to do, you know you’re going in the wrong direction.

Not redundant
You should not repeat yourself. If you’re copying & pasting logic all over the place, you’re doing it wrong. Try thinking about each line of code you put in, especially the ones you get from stack overflow

If you are declaring something that is going to be used multiple times in a code it is advisable to add it somewhere in constants, so later if you change that in a code, you just need to change it in one place, on the other hand, if you want to search that value as well, it will be easy to find it in the code. See the below example

Example of Bad Constant

if(users.getAge()>20){
//do something
}

Example of a Good Constant

if(user.size>ADULT_USER_AGE_LIMIT){
//do something
}

Easily maintainable
Use functions so don’t have to repeat yourself. Use patterns and OOPS principles. It’s all about limiting the scope of code to enable small, localized safe changes.

It’s about eliminating ‘if you change that here, you must also change this there’. It’s about having automated tests to detect changes that have broken other parts of the code.

Good and thorough commenting
Easily readable as possible by another developer. If you can get it as simple as possible, such that even a very entry-level developer could understand it, you have achieved a good thing.

The methods are organized in a manner that makes sense, with related functionality grouped together. It has comments that actually help you understand what’s happening.

A fine balance between speed and maintainability
Sometimes speed will be of paramount importance but you should always consider and weigh the importance against how much it will affect overall maintainability.

Stop being lazy and don’t call the same function every time you need a value when the parameter isn’t changing at all.

Short functions
Short functions help us understand the purpose of the function and also make it less prone to side effects and bugs. They are also easier to read. Functions and classes that do one thing and do it well. This goes along with the Single Responsibility Principle of SOLID.

Again there should only be one reason for it to change. Fewer side effects mean fewer bugs and easier maintenance, also better testability. Less than 6 lines function if possible.

Indentation is important
It’s easy to find where a block starts and a block ends. Something as simple as the right indentation can change your code from easy to read to a nightmare to follow.

Get a versioning system
Recommended system is Git. Most IDEs integrate version control systems. So, if you screw up, you can always roll back, or you can fork your project and experiment before making it a final version.

Test a lot
Write a lot of unit tests, and the time given will mostly not be enough. Demand more time as later people won’t remember how fast you did the work but how correctly will be discussed a lot. Think and discuss the impact a lot.

Care for exceptions and scenarios that can break your code. Don’t ignore exception handling, and don’t overdo it. If you are catching 7 different exceptions and just printing the log, you might consider catching the base exception class instead of 7 catch blocks.

Use standards
Google has some documentation for code styles for both java and c++and probably others. If you are dealing with languages like PHP and JavaScript, follow the style for quotes (single or double, where and when) that is used everywhere.

Before using a new feature of a language, make sure it is compatible with the production environment. Avoid misleading names or types.

e.g – Consider there is an array of strings and we wanted to add the user’s name to the array. 

Example of Bad Array Declaration

String userNameList[] = new String[10];

Example of Good Array Declaration

String userNames = new String[10];

In the above example, if we refer to the bad sample code, it is misleading the developer as it seems like the userNameList is an arraylist though it is only an array.