Clean Code — Should we prioritize hygiene in coding?
A good programmer are not only concerned with how the software they make can work, but also have a spirit of software hygiene. Should we wash our keyboard or mouse after we code? Absolutely no!😅
One aspect of software hygiene is how to write source code properly, so that the software can be maintainable and easily developed for the long term. Ofcourse, we want the code can be readable and agile friendly for the future change and development.
When coding, the coding style you follow can be really important. Specially when you are working with a team or you plan on sharing your code. Most of these guidelines are standard and can be applied to most of the programming languages, however, here you have applications and snippets with Javascript code, so you can familiarize with it easier. Remember that these are only recommendations for achieving clarity, which can be a personal preference, so take these pieces of advice into account but don’t take them to the letter. Sometimes breaking some of these rules can lead to cleaner code.
Why Should We Strive for Clean Code?
“Why should I care about writing clean code? Can I get the benefits from doing clean code? Isn’t it okay if I don’t do this?”
Clean code is readable and easy to understand by everyone whether the reader is the author of the code or a new programmer. Writing clean code is a necessary mindset. It takes practice to write clean and structured code, and you will learn to do it over time. But you need to start with the mindset of writing this way. And you’ll get used to reviewing and revising your code so it’s the cleanest it can be.
A good developer, when faced with a situation where they have to do something more than once, will generally find an automated (or better) solution to complete the task at hand. So because you’re lazy, subscribing to clean-code techniques will decrease the frequency of changes from pull-request code reviews and the need to come back to the same piece of code over and over.
Benefits of Clean Code
There are many reasons to get into the clean code mindset. Some of the most important reasons are:
Better Use of Your Time
The first beneficiary of clean code is the programmer themselves. If you are working on a project for months, it’s easy to forget things you did in the code, especially when your client comes back with changes. Clean lines of code make it easier to make changes. Less time, less effort wasted, right?🤔
Easier Onboarding for New Team Members
Using clean code principles helps to get a new programmer onboard. There is no need for documentation to understand the code; the new programmer can directly jump into it. This also saves time for both training the new programmer as well as the time it takes for the new programmer to adjust to the project😄
Easier Debugging
Whether you write dirty or clean code, bugs are inevitable. But clean code will help you to debug faster, regardless of how much experience or expertise you have. And it’s not uncommon for your friends, colleagues or managers to help you solve the problem. If you’ve written clean code, no problem: They can jump in and help you out😲.
More Efficient Maintenance
Maintenance does not refer to bug fixing. As any project grows, it will need new features, or changes to existing features. Do you know that the major cost of any software project is in maintenance? The company will always release the first version, or minimum viable product (MVP), as early as possible. Additional or new features are always an afterthought as the software gets more use. Clean code makes maintenance relatively fast and easy😏
“Of course bad code can be cleaned up. But it’s very expensive.” ―Robert C. Martin
Here are a few example of easy ways to apply it:
Use easily pronounceable names for variables and methods.
Do not use abbreviations in the variable and method names. Use the variable name in full form so it can be easily pronounced and everyone can understand it. Use the variable names that are clear and appropriate to the context, and make sure the writing format is consistent for all base source code.
In this example, I used ‘TabsSpvSekolah’ for the name of function. Maybe it can be confusing for some people. What does ‘Spv’ mean?😮
And then, I changed the name into ‘TabsSupervisorSekolah’. Is the name easier to understand?
Use the name to show intention.
The purpose of the variable should be understandable to someone reading the name of the variable. Write the name as you would speak it. This first example shows the unclear information of the variable, meanwhile the other one show much better descriptive information, right?😉
Clean code is self-commenting
Have you ever write comments for every line of code? You wrote some code and made sure that it was fully commented. As will happen, you found a bug, so you went back and changed the code. Did you remember to change your comments as well to reflect the new logic? Maybe. Maybe not. The next person who looked at your code then may have gone down a rabbit hole because they focused on the comments. Add comments only to explain complex thoughts; that is, don’t comment on the obvious. Fewer comments also reduces visual clutter.
Put Things in Order
Some of you may think to yourself that this isn’t even in alphabetical order. That’s only part of what this ordering scheme is.
Based on jsmanifest, order the imports for a clean approach is using these guidelines, in order of precedence:
- React import
- Library imports (Alphabetical order)
- Absolute imports from project (Alphabetical order)
- Relative imports (Alphabetical order)
import * asimport './<some file>.<some ext>'
Use Small Fragment over Large Fragment
When working with React, there are times when you’ll want to pass around groups of React elements. And while it used to be that doing so required you to add useless container components or confusing arrays, React solved this by using Fragments — a simple way to group elements without adding any extra markup. React.Fragment — is like a markupless component. When rendered to the DOM, its children will be rendered by themselves,
After using fragments for a while, you may run into a tiny issue: typing out <React.Fragment> is bothersome compared to typing <div>. And while this won’t get in the way when fragments are truly necessary, it certainly can slow down adoption. Which is why, I suppose, fragments also come with a concise new syntax:
Clean code is DRY
DRY is an acronym that stands for “Don’t Repeat Yourself.” If you are doing the same thing in multiple places, consolidate the duplicate code. If you see patterns in your code, that is an indication it is prime for DRYing. Sometimes this means standing back from the screen until you can’t read the text and literally looking for patterns.
Using Linter
Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter). A lint tool is a basic static code analyzer.
Linting is the process of running a program that analyzes your code for programmatic and stylistic errors. A linting tool, or a linter, marks or flags any potential errors in your code such as syntax errors or incorrectly spelled variable names. Linter can helps you and your team stay consistent with code formatting. It saves time, energy, and reduces the need to discuss the style in code reviews. It also enforces clean code practices which you can configure based on your opinions on what feels right and what doesn’t. For front-end development, we use Eslint to help us maintaining consistency with code formatting.
ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.
Conclusion
I hope that by doing clean code we can see the benefits of writing clean code and we can always implements it in the future software development. Clean code that’s readable and easy to understand by everyone can help us to reduce time, increase efficiency, and make it easier to debugging. Writing clean code is a necessary mindset that we prioritize when we code. Once you embrace writing clean code, it will become second nature.
I hope you enjoy my writing. Thank you! Keep your code healthy and clean😊
