How to Keep Code Smelling Fresh

Hello everyone and welcome back to the blog!

Today I wanted to talk about writing clean code and code smells, particularly as they relate to my journey through this process of developing better habits as I further my knowledge in the space.

To begin, there are a couple of things that I have found that really resonate with me, as they are things that I try to do, but not things I necessarily always do that I would like to do more consistently going forward. The following graphics come from

The first thing I want to highlight is descriptive naming, depicted below:

While this is something I normally do, just last week I ran into a situation where, when following exploration videos for a particular course, I was baffled at one naming convention, as it four or five words long. While I couldn’t believe this, and it seemed unnecessarily cumbersome, the more I think about it the more I realize that it is better to know exactly how something should be used than to have any ambiguity.

Additionally, I frequently see in certain classes the minimalist naming convention, which inherently makes me follow that convention in those particular classes, which can develop into a bad habit.

The second thing that stood out to me was the reminder that functions should only do one thing:

In the same class mentioned previously, in the same module even, there was function refactoring to a level that I had never experienced it. Again, it seemed ‘annoying’ and ‘cumbersome’, but digging more into this really makes me understand that is how it should be, and that is how you make concrete code. Boiling down functions to the bare bones is definitely a skill, and it is a skill that I would like to tune.

The second topic is that of code smells that I would like to avoid in the future, that I have a tendency to not avoid now. This information is provided by

The first thing that jumped out to me is Dispensables, defined as something pointless and unneeded whose absence would make the code cleaner and more readable. This is something that I often run into with duplicate code which can be refactored into a function, and in particular, comments. With comments, I am always told to have well commented code, but I often struggle to find the line between well commented and unnecessary comments.

The second thing that jumped out to me on this site was Change Preventers. This means that if you have to change one block of code, it forces changes throughout your code. This is not something that I necessarily struggle with too much, but it is something I would really like to avoid, and utilizing the aforementioned skills, it will eliminate the possibility of running into this smell.

As always, thanks for reading!

Print Friendly, PDF & Email

Leave a Reply

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