For this post, I wanted to talk about code smells. I picked this topic since it was related to my software construction course, and I believe I could benefit from diving into it some more. In my course, I feel like I learned much more about design smells, but not as much relating to code smells. A code smell is a characteristic or surface indication that shows there may be a deeper underlying problem with a code. Typically, they’re easy to spot, but I wanted to learn more techniques to look for these problems. In the past, I’ve discussed refactoring, and this ties into that nicely. Learning more about code smells will allow me to become better at refactoring. In order to learn some more about code smells, I listened to episode 88 of the Complete Developer Podcast which was all about code smells.
In the podcast, the hosts discuss what code smells are, as well as methods and techniques to find code smells. I was already familiar with some of the smells mentioned in the podcast, which makes sense. I’ve been guilty of many of these as I first started learning code. Naturally, as you learn to code, refactor, and improve, you start picking up on some code smells, even if you don’t have an exact word or phrase for what the code smell is. I was much more interested in the podcast when they started discussing object-oriented smells, since this is much more relevant to what I’ve been studying most recently.
The most interesting smell I thought the hosts discussed was the Refused Bequest smell. Simply stated, refused bequest can occur when a subclass only uses a portion of properties and methods inherited from its parents. Unneeded methods can go completely unused or in some cases, give off exceptions. This is something I had never given much thought to, but it makes sense after hearing the hosts discuss it. I usually try to reuse my code as often as I can, so I could see myself making this type of error where I try to tie classes together through inheritance just to reuse my code. I’ve learned about delegation and using it rather than inheritance, but it’s not something I’m as comfortable with as I’d like. This segment in the podcast led me to go back and study delegation some more to improve my grasp on it.