Throughout my academic career, I have sometimes found myself rushing to push out code, telling myself that I will come back later and make it better. But as the book Clean Code says, “Later equals never.” This is pretty much always true. I find myself slapping comments onto the messy code in an attempt to make it presentable. It’s likely a result of human nature and follows the old adage, “if it ain’t broke, don’t fix it.” While this saying has some merit, messy code that runs is still broken.
After reading about clean code and bad code smells, one thing I want to strive to do is ensure that my first draft is high quality and presentable. As I stated above, this has been a struggle for me. However, I noticed about a month ago that I had fallen into an even stranger and more subtle habit.
Coding in an academic setting often involves being presented with a difficult problem, that you don’t know how to solve, and then throwing ideas at the code-wall to see what sticks. So when I have been stuck on a problem in the past, and my first idea didn’t work, I frequently find myself saying internally, “I’ll just try this new idea” with little faith that it will work. Because I am in a rush for time and not even sure that my new idea will produce anything good, I write it in a sloppy way. I then iterate on this process until the codebase is done, and it’s a mess.
I don’t actually think this is an issue of not understanding clean code. I know how to write clean code, for the most part, and I even understand in that very moment I am not writing clean code.
So, if it’s not an issue of knowing how to write clean code, then what is it? For me, it’s improper planning. I often feel so strapped for time that I don’t want to put in the work of thinking out my code structure and logic before I begin writing. This may be fine in most academic settings; I always end up making the code look presentable before I submit. However, when bugs do occur, a block of messy code can actually really damage my ability to solve for bugs. Additionally, when I leave an assignment for the night, it takes me way more time than it should to understand what I just did the day before.
Ultimately, there is little excuse for messy code. While it may be a good short term method to maximize time savings, it won’t help in the long-run. Moral of the story: I am going to start writing clean code always, even for my first draft, and the way I am going to assist myself in this endeavor is through proper planning.
I won’t change overnight, but I am determined to correct this error. Because at the end of the day, messy code is broken code, and if it’s broke, we should fix it.
Brayden Edwards
Leave a Reply