Clean vs Dirty Code in React
Disclaimer: Hi everyone! I didn’t expect this article to reach a large amount of audience. Thank you for your insightful feedback. I am not at all a react expert and just started learning. This article is a weekly school assignment as part of my learning progress, so pardon me if you spot some misconceptions written in this article. Strongly advice you to refer to a more mature article to support this one. Thanks for understanding :-)
“Leave your code better than you found it” — Clean Coder
The traits of irresponsible developer
More time spent by programmers at work is on reading legacy code than on writing the code. Hence, your code cannot only be understood by you and The God. Others will take over your work. Imagine how would other people react if they seeing your code? If you are not confident yet, it’s probably because your code is not yet well written. A bad code has the following criteria:
- Not easy to understand
- Classes are tightly coupled
- Not easy to change
- Does not communicate the intent
- Shows too much internals (bad encapsulation)
Code smells are the sign of a bad code. For more specific explanation refer to this awesome article: https://refactoring.guru/refactoring/smells
The urgency to apply clean code
Either it’s due to pressure from the owner to launch the product quickly or you simply don’t know, a messy code won’t sustain. Fixing one thing could lead to breaking more things, reading code will take ages and prevent from improving the product itself. Sooner or later, if not fixed now, the product will be trapped in a death spiral. Let’s take a look at the comparison of a great company vs a bad company when developing a product.
Let’s Fix It
In this article, I will be covering four foundational parts that can enhance your code quality. Let’s get into it.
Naming
- Name must reveal your intention: Name must reveal your intention. The name of your function should be a verb, for example, setName, getUserAge, calculateDiscount, etc. Meanwhile, the name of your class and variable must be nouns. For example, Car class and carColor variable. Below are some examples of my code written in React JS as part of the IT Project course.
The first one is not intuitive. It will be hard to refer them later. An informative and concise naming like in the second example is much preferable.
2. Avoid Disinformation
The function above is parsing a number into a float with 2 fixed points. However, I named it toString which can be misleading for other users.
3. Avoid Lengthy Name and Encoding
Those are bad examples. The too-long name will take a lot of time to comprehend instead of helping. For the second example, I bet people except for the one who wrote that will be puzzled, “What is statChFrUsrInp???!”.
4. Class and Function Names: Class and object should have noun or noun-phrase names. Function names should be verbs.
Comments
“A common fallacy is to assume authors of incomprehensible code will somehow be able to express themselves lucidly and clearly in comments” — Kevlin Henney
Invalid Use Case
- Redundant Comments
Comments are inherently noisy. That is why you need to put them carefully. Do not put a comment unless it adds more value such as explaining something that is not declared explicitly.
2. Misleading comments
A comment that doesn’t match its functionality might occur because the developer simply forgets to update them. Do not forget to update the comments after you refactor someone else’s piece.
3. The journal comments
Your version control system can do so. No need to keep track in a form of comments.
Valid Use Case
- Public API comments
This is another level of comment, which is API documentation. It is very important to let public API consumers know what endpoints to use, how is the payload structure, and what they’ll return.
2. Legal comments
You must have seen this often, the use is to put copyright for your work.
3. Todo comment
4. Explanation of intent
All in all, a comment should explain things beyond what is written. It should be able to explain the intent of calling the block, who calls it, what is being passed along, etc if you feel the need to explain so.
Formatting
- Consistent Capitalization
Camel case for class name, function, and variable names. Class ( in this context is component ), should start with a capitalized letter. Meanwhile, function and vars start with a lowercase letter.
2. Spacing
Be aware of this failure. Your compiler is smart enough, no need to follow certain alignment.
3. Indentation can reveal things
Indentation infers cyclomatic complexity, a metric to indicate the complexity of your code. It measures the number of possible paths through your code. Thus, redundant example such as the following is not recommended.
Functions
- A function should be small and do only one thing.
There are so many things that happen in the App component. Let’s break it down into chunks of code to make each function can only do a specific task.
3. The fewer arguments, the better.
4. Prefer exceptions to return error codes
Clean Code Mantra
- KISS (Keep it simple and stupid) : Make your code simple and avoid complex incomprehensible codes
- YAGNI (You ain’t gonna need it): Create code only when you need them, never when you foresee you will need them
- DRY (Don’t Repeat Yourself): Avoid boilerplate, a code that aims the same thing but keeps being called.
- DIE (Duplication Is Evil): Every piece of knowledge must have a single representation that is unambiguous.
After reading this article, I hope we can be a more responsible developer from now on. You have now understood the urge of applying clean code, and you have known some applicable concepts. I hope that you can apply them in your next coding practice. We cannot be a hero in just a week, it takes continuous practice and hard work. Happy coding folks!
