Clean code is an ideal version of what a software product’s source code should aspire to. It is akin to a tidy office space, an organized file cabinet, or maybe a strategically laid out library. Navigating clean code is pleasant and refreshing, while a codebase that has little to no organizational or structural integrity would make me want to rip my hair out. There are many benefits to the production, cultivation, and maintenance of clean code outlined by Olivier Gaudin, in his blog post, “Why Clean Code is Important | The Power of Clean Code.” In the following blog, I will summarize my findings from a couple of informative blogs I encountered and share my thoughts on things I would want to do (or not do) with my own code going foward.
Some of these benefits for developers include:
- Boosts development skills
- Increases efficiency and productivity
- Creates a great work environment
Some of these benefits for organizations include:
- Reduction of reputational and business risk
- Lowers code-level technical debt
- Increases software development velocity
A company with clean code drastically improves their product by profiting off the aforementioned benefits, and more! Maintenance time and costs would drastically be reduced, developers’ work environments would be better, and the raw longevity of software would noticeably increase. Not only that, but runtime errors would be drastically reduced as well.
Of course, achieving clean code is not always the easy. Some companies source code is riddle with what the developer community likes to call, “code smells.” In order to understand what these code smells are, let’s first understand the term technical debt.
Technical debt, “consists of everything that makes your code brittle to future changes that make sense in light of how your understanding of the code and the domain grows over time,” according to Christiaan Verwijs. He goes on to explain that this could consist of a quick bandage of code to solve a recurring bug, an addition of one more method to an already bloated class, or any other action that prioritizes time rather than an overall better solution to a problem.
Once a program has loads of technical debt, it begins to smell. This is what coders refer to as code smells. These smells could introduce loads of bugs as well as an inability to deduce the problem and make the proper changes to procure a solution to said smells.
Going forward, one thing I want to attempt to not do is create a blob class. Blob classes are large classes that serve many different responsibilities, which are actively used throughout the codebase. This smell is also sometimes called a “God Class”. I tend to do this in my code sometimes to avoid needing to create separate class files and importing them into the file I need it. Sometimes I want to work quickly and not worry about the organizational aspect of my code. Unfortunately, this is an unavoidable pitfall that I’ll encounter if I continue to be lazy with how I structure my code in the future.
One thing I will attempt to do more of with my code in the future is to keep my classes from becoming too long or redundant. It needs to have a clear structure and shorter methods with parameters that make sense. Also, avoiding nested or branching statements within my class structure should help me maintain a cleaner and less smelly functionality in the end.
Overall, I learned a lot about the importance of clean code and how loads of accrued technical debt can lead to costly code smells. It’s best to avoid this outcome, as it wastes the time of developers and can greatly lower moral when the only work being preformed is maintenance or repair.
Sources:
https://www.sonarsource.com/blog/power-of-clean-code
https://medium.com/the-liberators/on-technical-debt-and-code-smells-ae8de66f0f8b