Don’t Make These 3 Mistakes While Coding
Coding is a fun activity, at least when we have clean code and don’t have many bugs.
Who has never seen something like this:
Let’s see some common mistakes we should avoid.
Duplicate Code
Duplicate code, or Write Everything Twice (WET) is a common mistake many developers make.
Who has never used Ctrl + C and then Ctrl + V in code, this is something very common that developers do.
The big problem with duplicating the same code is making maintenance difficult and duplicating bugs.
The best solution to avoid WET is DRY(Don’t Repeat Yourself), avoiding duplicate code, and creating common and shared code can bring many benefits. Usually, it has to be done carefully, to guarantee the Open-Closed principle, that way we can extend the behaviour to our use case if needed.
If you want to get deep on Open-Closed principle and others, you can check it out here: SOLID — Direct Way
Inline Documentation
Wait, I’m not telling you that documentation is a bad thing, actually, not having documentation is a problem, but we can talk about it on another day.
I’m talking about bad documentation, usually done by inline documentation. One of the big evils of inline documentation is explaining something that is obvious. Let’s see one example:
if(age > 21) { //true when have more than 21 years
...
}This not only makes the code harder to maintain because we are required to maintain this documentation, but also difficult to read, we have two things that have the same meaning.
In this case, I strongly recommend not using inline documentation.
The other very common case is using inline documentation to explain something complicated. Let’s see one example:
if(billingAccount.id % 10 == 0 && billingAccount.limit > 10_000 && billingAccount.limit < 100_000) { //This means that this account is for small businesses
...
}Now you can tell me that it makes sense, and I agree, but the inline documentation here is being used to explain something that should be easier, the best approach is to use a cleaner self-explanatory code. Let’s see the example:
if(isSmallBusiness(billingAccount)) {
...
}What do you think? Much better, right?
We should avoid inline documentation to explain something that the code can explain.
Premature optimization
Do you know the Big O Notation? Optimizing BigO(n) to BigO(log n) or looping through one iteration instead of two seems nice, but is it?
Sometimes we try to optimize the performance of our application without measuring, going from a BigO(n) to BigO(log n) with 10 elements is nothing, and sometimes we choose it instead of a better and cleaner code.
This is only one case, but there are many other examples, like using parallel iterations, that not only make things difficult to debug and read the code but also increase the chances of bugs.
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%.
- Donald Knuth
Like Donald Knuth’s quote, I’m not saying that using the right data structure or doing some architectural optimizations is a bad thing. We only need to be careful not to overwhelm things to have a micro-optimization.
Conclusion
By avoiding these 3 mistakes, we can create code that is easier to read/use and maintain. However, only knowing the common mistakes is not enough, it is essential to know also best practices and key concepts about your programming language and design techniques.
If you want to know some of the best practices to write a better code, you can check it here: Clean Code — Direct Way.
These are only 3 mistakes I see very often, but there are many more. If you know another common mistake, please let me know, and share it here 😄
