Take the 2-minute tour ×

Is there a need to differentiate using smells to find underlying problems and a term for common code smells. It's more about prevention like returning the milk to the refrigerator because you have a pretty good idea what is going to happen and just replacing it is not the best solution.

Edit: made a considerable change to the nature of the question, but still dislike the term.

share|improve this question

closed as not constructive by Macneil, Mark Trapp, Jonathan Khoo, Anna Lear Mar 30 '11 at 14:48


codificus uglibuttus? ;) –  Macke Mar 27 '11 at 16:04
Welcome to computing. Concepts are abstract. Words have to be created to describe the abstract concepts. Rather than merely complain, please propose your improvement along with your complaint. –  S.Lott Mar 27 '11 at 16:38
"not how I'd do it" ? –  Alnitak Mar 27 '11 at 17:11
@S.Lott This is a question-and-answer site. The OP had a clear and legitimate question. (That is, what can be used as an alternative to "code smell.") –  Maxpm Mar 27 '11 at 23:42
Jeff O: It makes me cringe too. If something is undeniably bad, e.g. Order1,Order2,Order3,Order4... as fields in a database table, I'd rather call a spade a spade and say that it's "crap" or "incompetently done" or "google normalization". But with something less egregious... meh. I just don't like the term "code smell" either. There is something pretentious about it. –  user21007 Mar 28 '11 at 3:23
show 12 more comments

19 Answers

up vote 35 down vote accepted

I worked in a large corporation which had absolutely no sense of humor. We used "refactor point" instead of code smell.


That duplicated code is a potential refactor point.


Personally I've no problem with the term "Code Smell".

Our problem was a zero tolerance on anything which may have been offensive:
Whiny Intern: He said my code smells! I'm offended and will sue the company!
p.s. this never actually happened, but they disallowed Code Smell anyway.

Refactor point - often following "potential" slid nicely under the radar, we knew what it meant and it didn't set off any - overly sensitive - "offencive" alarms.

p.s. At the same company, in a code review I was told to remove the comment "Nothing to do here, so get out of Dodge", reviewers comment was something along the lines of "You might find that hilarious but there are professional people here who are serious about their work". I - somehow - managed not the strangle the git.

. . . and yes I am aware that comments are a code smell :)

Edit - as suggested by E.Z. Hart (this is too good not to have in the answer)

"Potential Refactor Point" can be shortened to PRP and pronounced "perp".
Then all of your scrums/meetings/code reviews start sounding like a cop drama.

  • "We identified several potential perps"
  • "We're on the trail of the perp"
  • "We nailed the perp"
  • etc. :)
share|improve this answer
I really like the presence of "potential" in there. I am starting to get really fed up with people who (often pompously) announced "X is a code smell" as if it was a Known Fact and your stuff should now be ripped out. Potential Refactor Point is more accurate and less offensive. –  Kate Gregory Mar 27 '11 at 18:04
Maybe just Potential Refactor for short? –  JeffO Mar 27 '11 at 23:58
@Kate Gregory, I refuse to be afraid of or held hostage by my own language. "code smell" implies "potential", the issue may not be that particular line of code, but that's where the smell is noticed. –  zzzzBov Mar 28 '11 at 16:02
I see a difference between "comments are a code smell" and "comments identify a potential refactor point" -- the first is possibly rude, but more importantly it carries a sense of certainty that gets people's back up. @zzz, refusing (with words like hostage) to see that announcing something smells doesn't leave much room for disagreement is hardly the way to prove that "code smell" is a gentle and nonoffensive term. –  Kate Gregory Mar 28 '11 at 16:58
I like "Potential Refactor Point" - you can shorten it to PRP and pronounce it "perp". Then all of your scrums/meetings/code reviews start sounding like a cop drama. "We identified several potential perps", "We're on the trail of the perp", "We nailed the perp", etc. :) –  E.Z. Hart Mar 29 '11 at 15:41
show 5 more comments

Why use a negative label? Just say

I think the readability/maintainability/whatever could be improved here

And always be ready

  1. To explain how to improve it
  2. To explain why it's better your way.
  3. To hear why, just this once, you might be wrong!

EDIT because the question has changed!

Code smell is too emotionally charged. The author of the code likely has a strong sense of ownership and it can be hard to hear criticism. If you start right out by saying it smells, the subsequent discussion may generate more heat than light. Instead be positive and talk about potential improvements.

share|improve this answer
Any time you identify something that needs improvement it should be justified and you run the risk of being wrong. You're on the right track of introducing something less derogatory. –  JeffO Mar 28 '11 at 0:01
show 2 more comments

My submission:

Refactor Bait

(and if you say it really fast, it sounds kinda dirty)

share|improve this answer
Don't forget to use the Dalek voice. –  JeffO Mar 28 '11 at 15:33
show 1 more comment


The term technical debt was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.

Ward didn't develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it's a useful metaphor for communicating with technical staff, but I'm more interested in the metaphor's incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.

What is Technical Debt? Two Basic Kinds

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)...

share|improve this answer
show 1 more comment

Code Omen

From Wikipedia

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

Keeping true to this definition Code Omen sounds appropriate IMHO


Id like to add Why code smell in the first place? Because its catchy and simple in an annoying kind of way.

Smell is a symptom which indicates a future problem. a refined alternative to smell would be Omen which is also basically an indicator of a future problem. There wouldnt be a positive aspect to omen in this context as the positive aspect would mean every thing is fine and there is no point to be considered.

Potential refactor point would be good in comments. But is it as catchy ( say refactor bait) in speaking terms.

share|improve this answer
@SnOrfs - good point. Maybe the code part could be changed? My first thought was Bug Omen or to combine your answer, Refactor Omen. May need some work. –  JeffO Mar 27 '11 at 22:18
i like this best –  Steven A. Lowe Mar 28 '11 at 5:33
show 2 more comments

"Broken window" would be another term that comes to mind that hasn't been said yet.





share|improve this answer
+1 because it conveys more than just "rot" or dislike. –  NickC Mar 28 '11 at 17:28
show 1 more comment

Great question, I also loathe the term 'code smell' as ridiculous hyperbole.

I suggest

Code Stain

at least it's a valid visual metaphor.

share|improve this answer
show 1 more comment

I think the term "code smell" is going to be difficult to get rid of. It is an effective term because it is so evocative. You smell something bad, you start investigating and you find the source of the smell (an Anti-Pattern?) that might be a "potential refactor point" (thanks @Binary Worrier).

The only alternative I can think of at the moment is code smoke.

share|improve this answer
show 1 more comment

Two terms come to mind (I'm not a native English speaker though)

  • Quick & dirty solution

  • kludge

share|improve this answer
show 1 more comment

Maybe Anti-Pattern, even if I'm not sure it does match exactly the same idea. It's more than anti-patterns, it's more like "anti-structure".

share|improve this answer
The phrase "Anti-Pattern" doesn't really make too much sense. Is it a non-pattern? i.e. Chaos? No. It's clearly a recognizable pattern. So it must mean we're trying to apply some value judgement to the pattern. "Anti-" doesn't seem to provide enough value judgement. It seems more to indicate there is no pattern. –  S.Lott Mar 27 '11 at 19:32
show 6 more comments

At first I thought this was a great question. I still think it would be great if it was generating responses that could be synonyms.

However, after reading the highest voted answer, "potential refactor point", I feel like I have to say that is not a synonym, and neither are most of the other suggestions!

"Code smell" is good because it describes exactly what the problem is - the code may not be bad itself, it may not be anything on its own , but it is something has been known to indicate that there is a problem lurking somewhere.

The "smell" analogy is so good because if you start "sniffing" at the location of the smell, a good investigator can be led right to the problem!

One case which illustrated this to me well recently was the question Code Smell: Inheritance Abuse. After reading the question and answers, I started to notice inheritance trees in our own code that smelled. They weren't necessarily "potential refactor points" because they were only the surface where problem symptoms became obvious. The real refactor points are deeper underneath, but the investigation started at the inheritance tree.

When you fix the real problem, the smell goes away, just like a bad cabin air filter in a car, or mold within walls.

Just keep using code smell, but use it correctly and lets all try not to overuse it!

share|improve this answer
add comment

Normally when you have a lot of code smells, you might actually have a big ball of mud. So you can call it mud.

share|improve this answer
add comment

Code rot doesn't necessarily mean the same thing, but could be used in a similar context.

share|improve this answer
add comment

How about bad code? 99% of the time it's personal taste taken out of context.

share|improve this answer
show 2 more comments

Code Combustion: Trogdar, Burninator!

I think as it stands, the 'code smell' metaphor is apt. There is a certain subjectivity within each encounter. Some are distinct, and a consensus is easier to acomplish. Some might be considered subtle depending on the sensativity of the observer.

share|improve this answer
add comment

Principle Violation

I determine whether code is acceptable based on whether it violates SOLID principles, whether it engages in known anti-patterns, whether it violates a defined coding standard, etc.

So, if code (and its programmer) dare to violate principles surrounding these concept, then they've committed a principle violation.

Another thought: Code Sin

share|improve this answer
add comment


Because it stinks, code smell is not that precise, as it can also mean a "pleasant" smell.

share|improve this answer
show 1 more comment

A manifestation of inelegance

"Code smell" rolls off the tongue a little easier though.

share|improve this answer
add comment

If they are truly common, then maybe non-standard.

share|improve this answer
add comment
