Clean Code – What’s the Big Deal?


When I first started my computer science journey I was, as most are, generally focused on just making code that worked, never mind how it looked. Completing project specifications was the utmost goal and everything else fell far below in priority.

It wasn’t long before I started to understand why instructors cared so much about comments and concise, clear code when it initially seemed like a waste of time. Soon after beginning my learning I took a break from a project for a month or two and eventually returned to it to complete it. I didn’t think it would be possible to forget so quickly how your own code worked. After spending an hour or two just trying to remember why I wrote what and how one poorly named function related to another, it dawned on me why my teachers had been strict about clean code.

Clean code is not only important for others that may be potentially reading our code, but also for ourselves in future work or reflection. The shortness of memory of how it all works is impressive, and code that is written will be completely forgotten by the author in a matter of days or weeks. Tedious comments, clear indentation, and concise variable names seem like a time waste while trying to meet specifications, but can end up saving yourself and others hours of trying to decipher code’s meaning in the future. It is also a common trap to think that certain code will never need to be revisited or edited, but in my experience this is almost never true.

Although my code practices have come a long way, there is always room for improvement. A ‘code smell’ that I am continuing to struggle with is shortening up my functions, methods, and classes. I still have a tendency to just keep rambling on in my methods, and only creating new methods to avoid duplicating code. While this is one purpose of methods, they also serve to abstract code more and increase readability. In Martin Fowler’s book Refactoring: Improving the Design of Existing Code in Chapter 3 he states that bad smells include ‘Long Method’, ‘Large Class’, and ‘Long Parameter Class’. Each draws attention to the fact that the larger each body, the more convoluted and prone to errors it can become. While it seems counterintuitive to break things down into tiny areas, it greatly increases readability and ease of troubleshooting.

I still have a long way to go to writing perfect code, and the journey to perfect code is a never ending one. There are some conflicting opinions on minute details, and all of this is what makes coding fun and creative in the first place.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *