Happy 2025 folks!
I know we’re off to a strong start this year, so let’s sit down and relax a bit and talk about clean code and code smells.
The most un/fortunate thing about writing code that will be seen and used by other people is that the code will be seen and used by other people. Because of this, the beautiful mess that exists inside of your brain must be refined to such a degree that it adheres to some semblance of a standard. There aren’t hard rules to writing good code in the same way that there aren’t hard rules to success; one must exude a multitude of attitudes and habits in order to strive towards the ever-changing goal of writing “good” code.
There are do’s and dont’s on code writing that many programmers have more or less decided upon and I will discuss an article on clean code writing as well as one on code smells (bad practices) and speak on rules that I’ve seen personally in my own programming journey and yap about them.
Let’s begin with – Clean Code
I read this article from Free Code Camp: https://www.freecodecamp.org/news/how-to-write-clean-code/
They speak at length about clean code but the most important one that spoke to me was simplicity in writing code. While efficacy and efficiency are very important, (they’re listed near first in the article) to me, simplicity is just as important especially when it comes to readability.
In my opinion, code should be written in such a way that it is recognizable most of the time at a glance. I’ve known certain programmers to write very dense lines of code in an effort to display their syntactical skill boasting short run times and percentiles from their time leet coding, but more often than not the resulting code is an indecipherable mess.
Long, descriptive variable names, good spacing, and easy-to-follow code will make readability on a project so much greater and approachable. Two sections in this article that support this belief are “Format and Syntax” and “Naming” wherein descriptiveness and preciseness are praised.
Next up is code smells
For this issue, I read this article on code smells from 8thlight: https://8thlight.com/insights/common-code-smells
Rather than speak on one large concept, I’d like to touch on a few smaller yet important concepts mentioned in this article, the first of those being: duplicate code.
Any programmer who’s gone through any sort of formal education should have heard the acronym DRY at some point, which stands for “don’t repeat yourself.” I see reused and slightly altered code so much in programming. While it is also verbose and a big time-waster, this article point out that it also possibly can propagate bugs. Did you write bad code and use it in 18 different places? Congratulations, now you have to go fix the same issue in all 18 of those places. When getting to the root of the problem, the root best be in one place.
Another section is commenting. Often comments will be reiterative, will explain obvious concepts that should be self-evident through the code written, or just generally add nothing to the project. This article points out as well that the comments might reflect a previous version of the programme that doesn’t reflect its current state. When refactoring and updating code comments could be left to the wayside and end up confusing those who are newcomers into this code base (or yourself even if you haven’t read your own code in a while!). This is a trap you should avoid by only commenting when necessary and keeping it as up to date as the code is.
Thank you for taking the time to read my thoughts on prevalent code do’s and dont’s. These articles helped me see underlying, additional issues that might arise further enforcing good practices. Quite often we will be told how to comment or code by the established procedures set by the entity governing a project, but we must remember good practices WITHIN those parameters always and code well.
Have a good rest of your January, and stay safe and sane.
-Cody Hill-