Don’t Just Write a Code — Write a Clean Code
Let’s analogize about our hand-written software as a plant planted in front of your home. Your very first line of code is a seed to the soil. As you write line per line of your code, you let the plant grow bigger, bigger, and bigger… until the plant become so big and the roots crack your terrace’s floor. Certainly that kind of growth is not what we’re expecting. The same thing applies to our software development process.
What is a Clean Code?
Imagine you’re a software developer joining a company with an existing software developed. These software are sales software that records every single sales in the company, including the taxes. The system used to count the tax with 10% rate, but due to government regulation the tax rate changes to 11%. You are assigned to do the change, so you need to find the previous implementation of tax calculation and change the tax rate. As you search the code, you found this snippet.
You start to think “Is this the right implementation of the tax calculation?” “It seems to be right, but I don’t really sure from seeing the variables name”. When you’re seeing the git commit history, the code snippet was written by someone who has resigned from the company. Because everyone from the team doesn’t know it too, you try to change that code snippet and luckily your guess is right.
This type of problem is what we can solve with Clean Code. Without Clean Code, our computer can still execute the program well and returns a correct solution. But in case of software development in team, code readability is important and Clean Code enforces team to write code that is readable by humans
Best Practices in Code Readability
There is no golden rules of clean code implementation, but as software team grows we tends to make some convention on writing code in a project. These conventions is not a must to do, but it used to promote uniformity in the software development process among all team, even with all developers using that kind of programming language or framework.
There are some tools that can enforce us to follow some code style rules. It is called linter. Linter can be integrated with your IDE or text editor and automatically applies changes to enforce the code style. In some case, it will pop up some warning to our IDE if the changes need to be applied by yourself.
In Sikepa Backend project, we use Spring Boot Java and we can use Checksytle to enforce clean code. We integrate it with our CI/CD pipeline to check the codebase and generate report about the code quality. This function can be easily achieved by using Sonarqube.
Within the Sonarqube dashboard, we can see the exact line of code style violation, the violation type, and the advice of how we can solve the problem. Sonarqube helps us to write cleaner code and promote uniformity among the codes.
Gentle Introduction of “Uncle Bob’s Clean Code”
In addition of following the language’s or framework’s code style guideline, there’s another good guidelines of writing clean code that is commonly used by developers, regardless of what programming language or framework their used. The guideline is written by Robert C Martin or famously known as “Uncle Bob” titled “Clean Code” (http://cleancoder.com/files/cleanCodeCourse.md). You can read the book thoroughly to improve your sense in writing readable code, but there is a cheat sheet of the points written in the book (credits to wojteklu and axmachina)
Uncle Bob also write another book called “Clean Architecture” that makes software development more modular. We will cover this topic soon in another blog post covering Software Architecture and Design Patterns.
Thank you for reading this blog, see you soon in another PPL blog series!
