What Is A "Code Smell"?
Tags: codequality, tutorial, standards, programming
Published: 2020-10-03 00:18:29

If you've been programming for even a little while, you've probably come across the term "code smell".  You probably have a good idea of what it means.  And you've probably used it on numerous occasions.  But I'm here to tell you that it doesn't quite mean what you think it means.  Or, at the least, what **_I_** hear when someone says "code smell" is probably quite different than what **_you_** hear when the same words are uttered.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2kjkzfxlqlxcm6c454l4.jpg)
## The _Formal_ Definition
As a somewhat colloquial term, there's really no _official_ definition for "code smell".  So we're gonna start out with the basics - from Wikipedia:
<br/>

> In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem.

<br/>OK. So far so good.  This definition is probably as useful as any other.  But Wikipedia doesn't stop there.  The next sentence says:
<br/>

> Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

<br/>Hmm... Interesting.  Pay keen attention to that word "subjective", cuz that's what I'm about to dive into. 
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/rtxeou00xrjzivmy331m.jpg)
## The _Practical_ Definition 
In my experience, "code smell" all-too-often means this:
<br/>

> I can't quantify exactly _what_ I don't like about your code.    And I can't be bothered to explain this to a plebian like yourself.  But I don't like it.  So I'm just gonna dismiss it with the all-encompassing label of "code smell".

<br/>Obviously, I don't think this is the "definition" in _everyone's_ mind _every time_ they use the phrase.  There are plenty of benign uses of "code smell".  I've used the phrase myself.  Everyone has.  But I've seen too many scenarios where the use of the phrase falls under the definition I've listed just above.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/oq1t98i91tgehmo5zw7f.png)
## How Did We Get Here?
I don't remember anyone ever talking about "code smells" when I started my career.  When I read further on Wikipedia, this makes sense.  Wikipedia states:
<br/>

> The term was popularised by Kent Beck on WardsWiki in the late 1990s. Usage of the term increased after it was featured in the 1999 book Refactoring: Improving the Design of Existing Code by Martin Fowler.

<br/>That actually tracks quite well with my recollection.  There was some point in the mid-to-late 2000s when, seemingly out-of-the-blue, I began hearing colleagues shoot down coding examples as "code smells".  It was as if the term suddenly materialized in their brain and they seized upon it as a convenient (read: _lazy_) way to invalidate broad swaths of legacy code.

It's not that I have a problem with the phrase itself.  Nor am I bothered with (what I believe to be) its underlying premise.  Rather, I quickly became annoyed at the _way_ in which many of my colleagues suddenly felt empowered by the phrase to _dismiss_ other solutions with no further explanation or consideration.

I'd pull up a code sample - maybe something I'd written, maybe not - and before we could even proceed, someone would chirp up that it was a "code smell".  And... that was it.  Once someone throws out the "code smell" bomb, good luck getting them to rationally consider anything else that they see in that block of code.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/gfb7okfejnm7mu69t679.jpg)
## Talk To The Hand
Here is just a sampling of the kinds of code I've seen dismissed as a "code smell":
<br/>

* **Older Languages** - Look, I understand that many people hate PHP.  But code should never qualify as a "code smell" merely _because_ it's written in PHP (or any other language).<br/><br/>

* **Older Frameworks** - There are _billions_ of lines of jQuery out there in the wild today.  They're not going away any time soon.  Get over it.  If you wanna label every line of jQuery code as a "code smell", you need to ensure that you never ever work in a shop where legacy jQuery code still exists.<br/><br/>

* **Something Other Than Your Favored Paradigm** - Maybe every single one of your React components is written with functions and Hooks.  If so, then _Yay!_ for you.  Go eat a cookie.  And try not to sprain your elbow while you're patting yourself on the back.  But your religious adherence to functions doesn't meant that a class-based component is a "code smell".  It's just... _not_.  Get over yourself.<br/><br/>

* **Competing Coding _Styles_** - There are a million different ways to write the same set of instructions.  Your team has probably settled on their _preferred_ coding styles.  But that doesn't mean that other styles are "wrong" or "code smells".  For example, if you want the old guy to dump his `function` keywords in favor of all-arrow-functions, all-the-time, then that's fine.  _Talk_ to him.  Explain the standards _on your team_.  But don't be a jerk by just dismissing any use of the `function` keyword as a "code smell".<br/><br/>

You may be reading this list and thinking that _none_ of these broad examples truly qualify as a "code smell".  And you'd be right.  I'm just ranting about the fact that I've seen the "code smell" phrase used as a global catch-all for: "code that I don't like and I want to shame my colleagues into abandoning it".
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/iksn5582t34khsqxi5uo.jpg)
## Anti-Patterns
The code smell has an ugly sibling.  It's called the _anti-pattern_.  Just like "code smell", there _are_ legitimate times when something should probably be labelled as an "anti-pattern".  And just like with "code smell", the phrase is too-often used as a lazy way to discard alternative approaches - without bothering to quantify _why_ those approaches are bad.

I personally find _anti-pattern_ to be particularly affronting.  Because a "pattern" is neither _right_ nor _wrong_.  Patterns are "right" when they're used in the "right" scenario.  And they're "wrong" when they're used in the "wrong" scenario.  But once someone slaps that "anti-pattern" label on your approach, they're basically saying, "This should _never_ be done."  The problem with that mindset is that there are very few patterns in programming that should **_NEVER_** be used.
<br/><br/>

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cyk4i2vmp6qfgkvz7oj4.jpg)
## What Did We Learn Today?
Look, I'm not claiming that you should never label something as a "code smell" or an "anti-pattern".  I've done it.  We all do it.  And it's not inherently _wrong_.  But you should be careful that you're not lazily slapping it on things that you don't _like_.  You should always be able to quantify _why_ a particular code sample is a "code smell" or an "anti-pattern".  If you can't, then it may not be the code that stinks.  It may be _you_.

[AUTHOR'S FOLLOW-UP: Just today I found this excellent article from several years ago.  It really hits to the same points I'm trying to illustrate in this article, and I highly recommend it: https://www.cambiaresearch.com/articles/995518/six-reasons-to-ditch-the-term-code-smell]