Dietela: Automating Dirty Code Detection
How we utilize computers to read our code as humans do.
This article is written as an individual review assignment for PPL CS UI 2021.
Practicing effective communication in our team doesn’t only mean verbal and outspoken, but it also takes into account nonverbal communication. In this case, it is not limited to our body language.
It also should be reflected in our primary language among software engineers: our code.
The Essence
Clean? Code??
In a nutshell, a clean code is easy to read, reuse, and maintain.
Although clean code is comprised of a lot more than those three things, I’d say most, if not all, can fall into one of the three categories:
- Easy to read: Consistent variable naming, usage of constants, self-explanatory functions, and you name it. Anything that allows other developers to understand your code efficiently without bloated comments is included here.
- Easy to reuse: Small functions with little to no side effects, modular structure, design patterns, and all that contribute to less but effective coding.
- Easy to maintain: Predictable functionalities, tested implementations, and anything that shouts the code is bug-free and not prone to errors. Most importantly, the code can be modified without any heavy changes following it.
Clean code offers the values of efficiency and effectiveness in one package for you, your team, and anyone your code might have interacted with.
The Intelligence
Here, our Dietela developer team applies two-step verification to ensure a clean code implementation:
- First is obviously we attempt our best to write clean.
KISS: Keep it Simple, Stupid
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. — Bill Gates
Ironically, keeping things simple is not that simple. It requires the ability to do abstract thinking. Personally, I learn through experience and code references. Here are some examples of how I do the KISS principle in our project:
The code above is so straightforward that it is actually more lengthy to explain it. Here goes: we call API to retrieve nutritionists, store the retrieved data in a variable called nutritionists, and while it loads, Loader is shown.
For context, our project revolves around forms and displaying the result of those forms. So, we created useForm hooks to encapsulate all the tricky form handling logic.
It takes on an object parameter, consisting of the initialValues, custom validation scheme, and an onSubmit function that runs if the user submitted the form. In return, we can get the props for controlling our text and form fields, functions to validate and handle the form submission, and isSubmitting variable as an indicator if the submission is still in progress.
DRY: Don’t Repeat Yourself
Even in scientific paper, repeating yourself is equal to self-plagiarism.
When we notice something similar, the easy and quick solution is ctrl+c ctrl+v and modify. The short-term benefits gained from this, however, are not worth the one major tradeoff: sustainability.
Here are samples of how I implement the DRY principle in our project:
You might think extracting the hardcoded TextField components to a list seems like a minor change.
The real deal is that now the information regarding the text fields for biodata is centralized.
The list can be reused for both implementation purposes, such as creating validation schemes, and testing purposes, such as getting the form components through their corresponding placeholder.
Aside from extracting into a centralized list, wrappers are another perfect example to eliminate code duplication.
Wrappers allow us to implement the same configuration over many components without the risk of sustainability. If the implementation requires a heavy change, all we have to change is the wrapper component.
Linters
Last but not least, we apply standardized code rules for the whole repository and some from YAGNI (You Aren’t Gonna Need It) principle through linting.
Our mobile repository utilizes husky as pre-commit settings that will run eslint and prettify commands to automatically fix our code or manually point out code that disobeys the major rules.
And for the sake of transparency across the team, we supply lint CI stage as assurance that our code passed and thus is allowed to be pushed to the repository, at least based on the code style guidelines.
2. We then automate the process to detect our dirty code with SonarQube.
SonarQube gives you the tools that let you set high standards and take pride in knowing that your code meets those standards.
If our team happens to miss any dirty code pushed to the repository (either because of time constraints or merely human errors), SonarQube is there to point it out.
Once we set up and integrate SonarQube to scan our code, the evaluation can be seen in an organized manner (displayed below).
Although you may have written clean codes that satisfy SonarQube’s standards, you are only as good as your team. So, as long as the code remains in the repository, SonarQube will continuously remind you that the code has some faults.
Not only it provides automation and covers human errors, but SonarQube is also effective to push all the team members to follow the highest clean code standards, as it asserts the “pressure” of which our actions will affect the whole team’s evaluation.
