Code can smell really bad when it’s left out in the open. In the last six years, the biggest thing I learned about smelly code is that others than smell it too. So if code isn’t readable, organized, or built with safety in mind, it affects teammates trying to make it better. Thus, making code clean isn’t just a personal matter – but can make or break a team’s success.
This is much easier said than done, and in my experience so far, code smells are very easy to forget about, especially for personal projects. Organized code used to fall at the bottom of my priority list, especially when on a tight deadline. But when I started presenting my code and sharing it with others, having clean, organized code made the interaction more professional, engaging, and effective, since others can understand it and hence, care about it.
Who cares if my code smells?
On this topic, in the first chapter of Robert Martin’s book, Clean Code: A Handbook of Agile Software Craftsmanship, one of my favorite quotes is from Bjarne Stroustrup, the inventor of C++ and author of The C++ Programming Language.
“I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.“
A lesson I learned from this is the art of elegancy. Designing code in this way makes it enjoyable for the reader, easier to improve the codebase, and enhances efficiency. One of the best advantages to developing software is speed. However, just because the software works, doesn’t mean it can be improved easily past the alpha stage. But if the code is already clean, then I feel like the team’s ability to advance the project faster and stronger is more likely.
Another problem with smelly code is that it can be so unrecognizable that it’s difficult to learn. I remember one of my earliest programming projects where I needed to complete a Yahtzee game, and the conditionals and functions became such a big web that I just about broke down and had to take a break (true story).
A really good lesson I wish I learned earlier on is how to make functions shorter. In chapter three of Refactoring: Improving the Design of Existing Code, Martin Fowler writes:
“Since the early days of programming, people have realized that the longer a function is, the more difficult it is to understand. Older languages carried an overhead in subroutine calls, which deterred people from small functions. Modern languages have pretty much eliminated that overhead for in-process calls. There is still overhead for the reader of the code because you have to switch context to see what the function does.”
I strongly believe focusing on making functions shorter is the biggest key to designing a program well. On another note, switching context to see what each function of my Yahtzee program did is definitely something I do not recommend (lol). Long functions used to be the bulk of my program. Worse, it made the program difficult to understand and debug, making it impossible to complete the assignment in time. And was I proud of it? Not even the slightest.
But with practice, reprioritization, and learning from advice from reputable resources noted earlier, there is hope for smelly code.
Practice makes perfect, er, de’code’orant
Currently, one thing I would like to start doing more often is making functions shorter. In the past, I assumed that talented programmers can handle reading long lines of code… but that kind of mindset just makes everyone’s lives more difficult (including my own). By making functions shorter, the code is more readable and easy to understand.
A good example of this is how my team and I formatted our app.js file in our fire simulator game this year. Below is a screenshot on the file that configures all the settings of our game correctly using Phaser, an HTML 5 game framework.
Notice how each block of code is short with steps that describe what the code does. The file itself can probably serve as a singular function.
However, deep in the FireSpread.js file, I implemented a feature that allows users to extinguish fires using the water icon. I was short on time and new to the methods that were required, so this the slimy spaghetti that resulted:
Even though there are some comments explaining the output of the program, it’s unclear why each line is integral. This function also does more than light fire – it creates an animated object, generates the frames for it, plays the animation, makes the fire clickable, includes an event that detects when and how the fire sprite is clicked, and deletes the fire sprite when clicked. As you can see… that is some smelly code!
In the future, I want to avoid repeating this type of mess for each feature. Even though being feature-focused will be important for the current sprint, being elegant-focused will allow features to be easier to add, especially if every function in the program is readable and reusable.
Before I return to my computer to put some de’code’orant on this code smell, one thing to always remember from here on out: embracing elegance leads to embracing what matters.