Since the start of my programming career, I have always found it satisfying to rewrite my code in a way that does the same thing but is easier to understand. So, one might assume I am an avid supporter of “clean code,” which is actually not the case. There are quite a few benefits to writing clean code, but there are also some downsides that people forget to talk about.
Good Practices of Clean Code
Starting with the benefits of clean code, there are a few tactics one can use to make their code easier to read without much effort:
Avoid Deep Nesting
Every time you nest something that is one extra step the person reading your code has to keep in their mind. If possible, try to collapse nested structures into one level. If the code has already been executed beyond a certain point, then the previous code no longer needs to be taken into consideration.
Bad Example:
javafunction calculateTaxes(user, cart) {
if (!isMaintenancePeriod) {
if (user.isAuthenticated) {
if (user.isAuthorized) {
if (cart.total > 0) {
// Deep nested logic
}
}
}
}
}
Better Approach:
javafunction calculateTaxes(user, cart) {
if (isMaintenancePeriod) return null;
if (!isValidUser(user)) return null;
if (!isValidCart(cart)) return null;
return calculateRegionalTax(user, cart);
}
Eliminate Code Duplication
While I do not think you have to extract everything, especially if you are only using it once, you should try to extract logic into reusable functions. By centralizing repeated logic, you can make code more maintainable.
Use Meaningful Names
Some programmers find coming up with good names challenging, but this does not mean we should give up entirely. When naming variables, you should at least use descriptive names that clearly convey purpose and intent. This makes code more self-documenting and can eliminate the need for some comments.
Bad Example:
pythondef calc(a, b):
res = 0
tmp = a
for i in range(b):
res += tmp
return res
Better Example:
pythondef multiply(multiplicand, multiplier):
product = 0
currentValue = multiplicand
for count in range(multiplier):
product += currentValue
return product
Where the Problems Start
I do not think clean code is a bad idea, but I have a few issues with it.
First, not everyone agrees on what “clean code” means. Does it mean having very short functions? Does it require continuously extracting functions to make them more abstract? Do functions really have to only do one thing? The answer to these questions, and many more, will change depending on who you ask.
Now, there are a few things I do not like that are sometimes considered “clean code.” First, the idea to keep functions extremely short (2-4 lines) is impractical and can lead to fragmented, hard-to-follow code. Excessive function granularity makes code harder to follow by forcing readers to jump between tiny functions.
Another issue is that premature optimization of code flexibility can lead to it becoming unnecessarily complex. I have noticed that writing clean code sometimes leads to over-engineering and feature overload. If you follow something like the DRY principle 100% of the time, it can lead to over-abstraction and hard-to-maintain code. People spend so much time turning a simple program into a framework-like program when they could have used the time better somewhere else.
I recently read an article that discussed some of the issues with “clean code,” specifically Robert C. Martin’s Clean Code book, more in-depth. The book itself is already pretty outdated, but it is an interesting article.
When Clean Code Is Worse
Here is a video that talks about how clean code principles can significantly hurt performance: “Clean” Code, Horrible Performance
In short, this video talks about and gives examples of how common “clean code” principles can impact software performance. One of the examples the YouTuber gave was using polymorphism over switch statements and hiding internal implementations, which can make code 15-24 times slower since it requires more cycles. Now, there are languages like Rust that let you do zero-cost abstractions, but that is not the case with many languages. The video goes into more advanced options, which significantly improved performance but broke even more “clean code” rules.
Now, clean code is not necessarily a bad thing, but one should not blindly follow these rules without considering their significant performance implications.