Clean code. If you are a Computer Science student at Faculty of Computer Science at UI, you might have or would know about this topic from the Advanced Programming class on semester 4. This is one of the things that should be done in order to fulfill a software craftmanship (an approach into software development that emphasizes the coding skill of the software developers) in agile methodology. Then maybe to recall, what’s the definition of clean code itself?
Clean code is a code that can be easily read, understand, and add to by other developers. Because when you work in a team, you need your code to be easily understood and maintainable by other developers. And you know, even by yourself because if your code isn’t clean, there would be some cases where you can’t even understand the code that you wrote yourself in the past.
“Programming is the art of telling another human what one wants the computer to do.” — Donald Knuth
Why Clean Code Matter So Much?
Clean code is critical in software industry because it perceives what makes or breaks the project. Clean code matters so much because implementing it would help reducing technical debt in a project. It also would help saving our time, because when your code isn’t clean, you and your fellow developers in your team would need to spend a lot of time understanding the code you’ve written. Also, the more code we write, the higher its complexity would be, and the more expensive it would get. So, writing clean code will saves us a lot of time and cost.
Then How to Write Clean Codes?
We need to get used to it. That’s the key. Understand the rules first then practice. Which rules? Oh here are the cliché rules that I recalled learning in my Advanced Programming class:
1. Follow a consistent coding standard
We can also install helpers like linter or CS Fixer from a certain established industry to follow the standard guidelines of the programming language we are using. Integrate the build tools in Sublime or Visual Studio Code or any of your preferred code editor to automate this. Then to make sure, include this on your production pipeline like the checkstyle pipeline my team implemented on our project below. The point is just to make it easy for everyone in the team (including yourself) to read the written code.
2. Name things properly (long variable and function names are allowed)
Besides that, when writing a variable name, it’s best not to use abbreviations like abbreviating “permohonanPenyitaanTable” into “ppTable” for example. It’ll give your teammate a hard time in understanding this. It’s better to use long variable name instead of an unclear, short one. And this doesn’t only apply to naming variables, but also function/methods, classes, files, folders, etc.
3. Keep It Simple, Stupid! — KISS
The maximum indent per method is 2 or 3 (in case of exceptions), unless yeah, you’re coding in HTML. You can do this by avoiding the use of else in your conditional statement. Implement this by using early returns, and throw your exception instead of using else. You can see in the example below:
And you can write more precise logic strategy to reduce indentations like the example below, where you can actually write a smarter methods to reduce nested loops:
4. Avoid creating a god-like objects and long methods
Like in a Singleton Design Pattern, a method is best to only work on one task, and a class/object needs to only be focused on the things related to them. Avoid using “and” in method names, like validateAndSave for example. It indicates that the method has 2 functionalities and it breaks the rule that a method should only do 1 thing only. Keep methods small, 50-ish lines are usually enough to solve one problem. As you can see on the example from my project below, that’s a method/function that’s only made to solve one problem, to refresh a table and that’s it.
5. Don’t Repeat Yourself! — DRY
6. Avoid comments
In my Programming Foundations class, I used to explain every single method/function, or even line I made in the comment lines, and it is not the best practice in the clean code. I remember once one of my professors told me that the code should speak for itself. The below example is a bad practice:
This could be refactored into a smarter way like below:
Comments are code smell (anti-pattern). If you need to write comments for your code, it means that you need to put it into a new method.
Then how is writing clean codes affecting me and my team?
But there’s also one time when we got warnings on our checkstyle pipeline and the debugging of that was pretty complicated and takes time. But we managed to solve it!
Welp, that’s all from me, though. Thank you for reading, hope you get some insights into writing a cleaner code. Have a great day!