Why should every web designers and developer, including you and us should care about clean code?
Design principle applied here. Clean code not just aesthetically looks good but the more important part is it allow the developer team’s speed to maintain and deliver more functionalities in an existing project. One thing all developers should keep in mind when writing codes is they are not only write codes for machines but also for humans. In practice, most of the time developers works in teams. So, if you write codes that only you can understand, it will slow down your team work-pace. To avoid that hassle, you could follow these simple coding rules.
The boy scout rule
Leave your code better than you found it
That may seem like an obvious advice, and it is! But it doesn’t mean we have to write a perfect code. Instead, refactor or improve our code gradually and as frequently as possible. By having this improvement mindset, we will code faster because we don’t get stuck trying to achieve perfection in first couple alterations, which will take a long time and almost impossible to achieve.
Variables
Variable naming is often overlooked and ignored. This result in random names that don’t make any sense to you and your team. Follow these two tips, your team and yourself will thank you.
- Meaningful names
- Pronounceable/Searchable names
Comments
If you feel the need to write a comment, try to refactor your code first, in a way that it will be self-explanatory. Yes, we agree in some cases comments is needed, but try to minimize the most you can. Because there is always a risk that your comment will be left behind in terms of updated to your code, leading to confusion afterwards. And when you write comments, make sure they are good comments. It is easy to differentiate good and bad comments. Good comments have purpose. For example:
Warning of consequences: This one should be used moderately, but it could prevent unwanted consequences from happening.
TODO/FIXME: They can be used as reminder, but if written in the project must be prioritized to not accumulate all over the project. Usually that is better controlled outside of the project.
While you can gain some insight from good comments, bad comments wont give you any new information. Signs of bad comments are:
- Redundant
- Comments vs Variable/Functions
Usually well named variables and functions gives a good notion of what it does. Bad comments explain about the variable/functions when it is not necessary. - Commented-out code
This one a caught ourself falling into it. The problem is if you comment a code and let it stay in your project, no one except you will know if they can delete that code, because it certainly has a reason to being there instead of deleted. If we keep doing that practice, we will overload our project with undesired polution of commented code (of course, there are exceptions for this).