We Should Keep Our Codes Clean!
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
For example, if you’re coding in PHP, you can follow the PSR-2 standards. Another languages like Python, Java, JavaScript, etc. also have their own standards. For example, in variable naming in Java, they are using camelCase, meanwhile in Python, they’re using snake_case.
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)
This point is pretty much related to the point above. Stick to the convention. Like me, I’m coding in JavaScript for my project, and JS uses the camelCase convention, so I name my variables in camelCase as in the example below:
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
In my project, me and my team is using Svelte, a JavaScript framework for building interfaces. Just like React, Svelte can be used to build reusable components. Reusable components is a great way to not to repeat written codes. You can just create one component and then export it into many pages where that component is needed. As you can see below, Sheet, Searchbox, and PermohonanPenyitaanTable are reusable components. We can just import them from any page where we need to use those components at.
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?
Writing clean codes have given me and my team many advantages. I feel less burdened because writing front-end codes with a JavaScript framework like Svelte that supports the reuse of a component to avoid repetitions saves me a lot of time. Also, the convention in naming variables helped us too because there are like 5 different people working in 1 same project, which would be pretty jumbled up for other people to read my code if I don’t follow the naming convention. Line one time when I was about to integrate my front-end codes with the databases using JSON, the variable names style from the part that my friend was working on was kinda different than the other variable names style my other friend was working on and that was pretty confusing. So yes, writing clean code has helped me and my team a lot.
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!
