Is "Code Smell" still a useful metaphor, or has misuse of the term subverted its meaning? [closed]

Question

I've come across some comments and answers on Programmers.SE that decry the use of the phrase "Code Smell" and I've been wondering what the reasoning is for those who dislike it. I first encountered this term when I read Fowler's Refactoring back in 2000, yet it's only in the last year or two that I've heard any complaint about the use of the phrase.

Q: Would it be correct to say that the phrase Code Smell has recently started to fall into disfavor, and if so why does/should this metaphor no longer apply?

---

I am looking for well defined answers supported by sound reasoning as I realize that this question is borderline subjective.

Answer 1

The term suffers from what all conceptual mixed metaphors suffer from: Ambiguity. What exactly is considered code smell? Jeff Atwood assembled an extensive list of code smells, but if you go through it, do you feel confident in saying that we (or any other two developers) would apply the term to the same conditions?

It's just a silly little metaphor that, as all silly little metaphors, was never intended to be taken seriously. When Kent Beck coined the term, this is what he had in mind:

A code smell is a surface indication that usually corresponds to a deeper problem in the system.

Code smell is a hint that something may be wrong, a red flag that you should investigate further, and not a generic label for bad code. It's an extremely accessible metaphor, translatable to most languages (I think?), relatively easy to explain to beginners, coined by Kent Beck and popularized by Martin Fowler (read: hype). Hence, prone to abuse.

Most mentions of the term on Programmers.SE are replaceable by a more specific term. Not necessarily a more formal term, just a more specific one, that would guide answers a bit better. There are even some "code smell" questions that aren't actually about something awry in the code itself.

In the context of Programmers.SE questions and answers, it would be preferable to avoid metaphors, idioms, analogies, and other literary devices. Every ambiguity is a potential comment war, and literary devices are prone to be interpreted differently per level of expertise, and don't always translate to the world wide audience of the site. As Bjarne Stroustrup put it best:

Proof by analogy is fraud.

All that said, I really like the term and would never give grief to anyone for using it.

_{Is any of this on topic?}

Answer 2

I had a old woodworking teacher as a kid who wanted me to remember to make sure that I didn't leave a mess with varnish on my completed projects. He gave me a silly sounding name to remind me to clean up the varnish before it dried, saying that if he called it something nice I'd forget it, but a silly name I'd remember for ever. He was right, and to this day I associate the word "snotters" with drips of varnish left to dry and make a woodworking project look ugly.

There is power in naming things. We know this in how we sometimes agonize over how we should name our classes and variables in code, and how getting names right helps to define the content of our methods. Likewise I am sure that this is the real power in using an analogy to describe a concept as ephemeral as the potential for a design problem in working code. Agile developers like to get it to work, and then refactor to get it to work better, however a sensible approach needs to be employed to ensure you are refactoring for the right reasons. As Yannis has correctly stated (and I'll paraphrase), that which seems bad to one person may not necessarily be considered bad by another, and thus the potential for a problem does not logically imply the actual existence of a problem.

Perhaps the analogy isn't quite accurate. Maybe a touch, sound, taste, or visual analogy would be more direct. However the problem with applying a non-olfactory analogy is that it is hard to come up with a good short name to describe code that might end up bothering you in some subtle way, while the word smell implies a subtlety that might have otherwise been overlooked had it not been for some factor that brought it momentarily to your attention. What I like about using the word smell is that it offers a way to describe that something may need to be looked at for further tuning, while not necessarily implying that there is anything wrong... like a good and stinky blue cheese might smell awful yet still taste nice. It's subtle - the phrase... perhaps less so the cheese... or this analogy!

Possibly one of the reasons that code smell seems to be treated like bad air on Programmers.SE (yes, pun intended) is that many questions tend to ask "is this a smell", yet without providing enough context. Thus we end up with a pretty useless series of questions that resemble the following:

Q: Could it indicate a problem? A: Maybe/Potentially.
Q: Does it indicate a problem? A: How will we know without reading all of your code?

Perhaps the underlying issue with people not liking the term "code smell", or perhaps more precisely the reason why many people misuse the phrase, is simply because their definition is being taken from a purists perspective, rather than pragmatically, or perhaps they simply misunderstand what the analogy of a code smell is really meant to represent. Based on the C2-wiki's Code Smell definition it appears that the meaning of the phrase remains sound, and it's usage continues to be applicable, while my now lamented woodwork teacher's wisdom also remains sound, because like Snotters, the phrase Code Smell is hard to forget and will likely continue to be used - and possibly abused - for a long time to come.

Answer 3

In electronic design, I've come across things that just don't make sense. When you look at a circuit and think: "That's silly. There is no sensible reason... it looks like they just plucked something from the air and tried it and a sample of 1 actually by a miracle worked".

That's a design smell. It just pongs of something bad and not quite right. (And gets confirmed later by a complete lack of documentation, and also analysis showing dodginess.)

This kind of thing happens in many fields, and the idea of "smell" as a general feeling of something being not right and needing further digging is a perfectly good one.

The does seem to have been co-opted into a more general expression of a difference of point of view, along the lines of "I don't like your object hierarchy, I think it sucks, so you have code smell". This might be the reason you sense a possible falling into disfavour: subjective difference of opinion vs intuitive feel of not quite right... not the same things at all.

Answer 4

Code Smell is a great metaphor in my mind. In this context, "smell" means "stink". Stink tends to indicate that something is rotten; something is not good; something will make you sick. Stink refers to something that is inherently unpleasant.

When I say that there is "code smell", I believe that I am unambgiguously indicating that something seems very wrong with the code I am referring to. However, as in the case of "stink", it may not be immediately apparent what it is.