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.

closed as not constructive by Jarrod Roberson, gnat, yannis, Thomas Owens, Caleb Feb 6 '12 at 20:28

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    3 close requests, and yet no suggestions as to how this question could be improved :( – S.Robins Feb 6 '12 at 6:47
  • 6
    I think the question is very close to the definition of "not constructive". The I want to be clear that I'm not attempting to invite debate doesn't really help, it probably makes it even more "not constructive", in a similar manner than slapping "as a programmer" to an off topic question doesn't make it on topic. The one obvious flaw is that you don't provide any evidence for your premise. I happened to see some anti code smell comments, so didn't give you any grief about it, but still you should at least link to a couple of P.SE posts that decry the use of the phrase. – yannis Feb 6 '12 at 8:44
  • @YannisRizos Less a premise, and more an observation based on what I've seen recently, leading to a question which I believe I've phrased as such. If it seems misleading in that regard, I'll try and rephrase. The disclaimer certainly wasn't meant to be viewed as a means to hide something others might think is off-topic. Given it's programming specific terminology I felt the question to be definitely on topic, but didn't want to have answers to make it appear otherwise. But, point taken, I'll rephrase and will also see if I can wrangle in a couple of links. – S.Robins Feb 6 '12 at 9:43
  • 1
    The disclaimer shouldn't exist at all. The phrasing / wording of the question itself should be guiding answerers to what you are / ain't looking for. Still, it seems that the close votes are frozen at 3, so take all of the above as extreme nitpicking. Obviously I don't want the question closed, I found it interesting enough to provide an answer. But then again, I did vote to close, it's part of the review process that drives the site... – yannis Feb 6 '12 at 9:52
  • @S.Robins: I like the subversive nature of this question. The determination of what is objective or subjective on this site is very subjective. Good job trying to defuse the potential objections from the FAQ! – Sam Goldberg Feb 6 '12 at 20:36

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?

  • 1
    From your link: "You can't prove anything from an analogy, only hope to improve informal understanding. Abuse of analogies can teach people to hate analogies completely. However, sometimes they can be used to good effect." I'm not sure I would necessarily connect popularization to being the primary reason for abuse. Perhaps it is simply a case that those who abuse it have probably missed the point of it. – S.Robins Feb 6 '12 at 5:34
  • @S.Robins Hmm... I don't hate analogies. I find them an inefficient communication mechanism, strictly in the context of Stack Exchange posts (which your question was mostly about), where specificity is key (the whole expert thingy). Of course their abuse originates in misunderstanding the term (as does abuse of everything), and popularity plays a part, simply because the more popular the term is, the more people are likely to abuse it, and the more crap questions we are likely to get. – yannis Feb 6 '12 at 5:44
  • I gave you a +1 mainly for that link! :P I guess the real question is whether the metaphor itself is one that is widely translatable, unlike many others that are mistakenly used - and sometimes mistakenly accepted - as proof. – S.Robins Feb 6 '12 at 6:04

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.


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.


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.

  • 2
    :) That's exactly the problem with the term, for most people it translates to "stinks", when it wasn't intended to only mean that. There are good smells, and there are weird smells (weird but not necessarily bad). Code smell is just an indicator that something deserves a bit more investigation, but there is no certainty that what you'll find will be bad, or that you'll find anything at all. – yannis Feb 7 '12 at 7:56
  • Technically, "smell" can refer to a good or bad smell, but in the common usage in my neck of the woods, a good smell is likely to be referred to as a "fragrance" or "aroma" – Rice Flour Cookies Jun 6 '12 at 21:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.