There is something about revisiting code that I’ve written in the past that is (for obvious reasons) often embarrassing to no end but also powerfully encouraging. At the time when the code was being written it showcased most all of my knowledge and largely the full length of my ability as a programmer. I rarely went into a project without presenting my best foot forward and trying my darnedest to be clever in my implementations but now looking back, I can instantly see flaws not just in logic but in styling and cohesiveness. I wrote very verbose code (sometimes I still do but make my best effort to minimize this) that made comprehending my code nearly impossible in a limited timeframe. In full transparency I viewed a lot of the “software engineering” courses to be a waste of time when they mainly focused on clean code and code smell and organization because it all sounded very obvious and full of extraneous examples of rights and wrongs. Now there is tangible evidence that I have (whether subconsciously or intentionally) taken those guidelines to heart and make an active effort to use techniques to increase the cleanliness of my code. Clean code not only makes understanding and maintaining code easier for the initial writer, it allows others who may have no access to the original writer able to read, understand, and contribute to the same code seamlessly.
Something from Robert Martin’s “Clean Code: A Handbook of Agile Software Craftsmanship” that seemed incredibly relevant to me when looking back at my old code was the idea of meaningful naming conventions for classes/methods/variables etc. This is something I actually did practice a lot in my beginning coding courses because I would otherwise get lost in my code and forget what each variable actually represents. Not to mention we would have received a 0 grade if we refused this naming convention. I eventually got more comfortable with reading and comprehending my own code that I dropped those practices to make things quicker for me. This created a lot of issues when I started collaborating with others and eventually had to make my code more accessible to other contributors.
Here is an exaggerated example that portrays a similar issue:
In some cases it seems like a time saver to take shortcuts when writing code and there are good intentions when doing this. There are times where I find myself naming variables and others using random names or the first letter of a word just for the time being so that I can get all my ideas out as I’m thinking of them to prohibit losing my flow due to the tediousness of writing meaningful and descriptive names. This is fine if you’re willing to go back and clean up your code for other programmers to interact with but either way it is a good habit that I want to do more moving forward. Its one incredibly simple thing a programmer can do that makes a huge impact down the road.
References:
– Martin, Robert C. *Clean Code: A Handbook of Agile Software Craftsmanship*. 1st edition, Pearson, 2008.
