Talk:Code smell

(random heading)
(inserted randomly for random readability ... said: Rursus (bork²) 09:05, 9 July 2009 (UTC))

For a September 2004 deletion debate over this page see Votes for deletion/Code smell

There might be three Perl people that use this term, but it's very rare, an article is on the very edge of validity. This would make more sense as a single sentence in design pattern (computer science) or some such. Stan 03:45 26 May 2003 (UTC)


 * I like the phrase but it seems to be an original invention: WP:NOT: If you invent the word frindle or a new type of dance move, it is not article material until a secondary source reports on it. Wikipedia is not for things made up in school one day. --Fasten 20:22, 12 April 2006 (UTC)


 * This term has been around since at least 1999, is commonly used by developers following Extreme Programming, or similar, methodologies -- particularly in discussions involving refactoring. I have two books on my desk that each have a chapter devoted to the topic.  There are numerous other books (that aren't on my desk) that would also cover the term.:
 * kenj0418 17:01, 13 April 2006 (UTC)
 * kenj0418 17:01, 13 April 2006 (UTC)
 * kenj0418 17:01, 13 April 2006 (UTC)


 * I suppose in that case you can add them to the article. --Fasten 17:32, 13 April 2006 (UTC)
 * I just tried to verify your claim but apparently I didn't buy Fowler. I remember somebody recommended it and I browsed through it but it probably had the wrong smell. --Fasten 17:49, 13 April 2006 (UTC)

Removed Dubious Example - Code Generation
Whether or not code generation is a code smell is debatable. The article indicates that it violates once and only once but code generation can be a way to achieve once and only once in a programming environment (language, target platform) where that is not otherwise possible. Since this example is dubious and the article does not lose the ability to demonstrate the concept of a code smell without it, I've removed that example. (Be_bold) 216.36.186.2 (talk) 13:08, 4 February 2008 (UTC)

Requirement contrarinesses
At a superficial overview, it seems that the criteria for code smell are sound, but reading the link A Taxonomy for "Bad Code Smells" it seems that the duplicate code criterion counteracts the inappropriate intimacy and the large class/method criteria. An indication of this is the late introduction of generics in Java, which gives at hand that there is a general, longlived and naïve belief that "classes can do it all". For the article, which fulfills a very important purpose, I propose enhancing the criteria list, to problematize what the real problem is about and how the OO philosophy, especially XP philosophy believes that this real problem should be solved. (For the far future, I would hope there emerged some numeric measures of a fair balancing of one criterion against the others, but if CompSci ever reaches there, it will take decennia). ... said: Rursus (bork²) 09:16, 9 July 2009 (UTC)

Citation not needed?
"Determining what is and is not a code smell is often a subjective judgment" misspelling + does this really need a citation? It seems like common sense to me. —Preceding unsigned comment added by 212.85.4.179 (talk) 12:59, 14 October 2009 (UTC)
 * I agree. Btw, judgment is not misspelled.  Mahanga Talk 14:00, 14 October 2009 (UTC)

Mention other bad practices
Like bad naming, etc. bkil (talk) 16:58, 3 November 2009 (UTC)

Some additional smells I routinely encounter:

- Use of globals (in those languages that support them) where reusable objects would be better.

- Use of switches to achieve variant behaviors where polymorphic objects would server better.

Mohanchous (talk) 13:02, 11 October 2010 (UTC)

Ubercallback ?
Is this a common term (Google only shows up cuts-and-paste from wikipedia)? Isn't a "callback that does everything" a reasonable artefact of the Strategy pattern? 217.194.34.115 (talk) 12:04, 13 January 2012 (UTC)
 * 18+ months later, still no Google results apart from wikipedia. Should delete that term. 83.226.155.15 (talk) 21:06, 8 October 2013 (UTC)

Proposal to merge with Refactoring
I don't know who proposed that this article be merged with Refactoring (and I am surprised not to see discussion about the proposal on this page). I'd just like to say that I disagree. In fact, I think this page should be expanded to encorporate more information about each smell, with examples and alternatives where possible. This article could ultimately become quite extensive, and as such, it would be inappropriate to merge. Kmote (talk) 20:00, 12 July 2012 (UTC)


 * Update: Ah, I see now the link to the previous (now dead) Talk page about this matter. Seeing that the debate has been decided in favor of Keeping, and that the discussion is nearly 8 years (!) old, I propose that the banner be removed. Kmote (talk) 20:09, 12 July 2012 (UTC)


 * I agree on both counts. Since no one's shown up to argue for the merge, could we just remove the banner now? I'm not very familiar with wikipedia's rules of order. Inhumandecency (talk) 17:54, 23 July 2012 (UTC)


 * The proposal may have been made many years ago, but the page now says that the merge with Refactoring was suggested in February 2012. I do not agree with merging. The notion of a code smell is wrapped up with refactoring but it is a separate concept. Additionally, there is little reliable and stable information on the web about Code Smells. Martin Fowler has a short explanation on his bliki - http://martinfowler.com/bliki/CodeSmell.html- the list he refers to at the bottom of the entry is broken (but it is also at CodingHorror.com and is linked here as an external link). I do agree that the banner should be removed.  Rdryfoos (talk) 23:09, 2 October 2012 (UTC)

I also do not agree with merging. The ACM Digital Library now has hundreds of articles relevant to this phrase, so it is clearly a legitimate topic of research, and therefore an important term to define. BradMyers (talk) 14:26, 27 October 2012

I do not agree with merging as well. Code smell could be a hint to bigger problems with the design, interface and arrangement of the code. Code refactoring could be a solution to such problems. As said above they are certainly related, but both deserve separate and extensive pages. hkdobrev (talk) 23:34, 31 October January 2013

Since the consensus seemed to be against merging, I removed the merge template. And by the way, the previous edit by user hkdobrev was made in January, not October (which is still in the future as of writing this), so I corrected the timestamp. Teemu Leisti (talk) 15:50, 18 February 2013 (UTC)

There is no such thing as 'code smell'
And thats a fact. I know that the codersphere is now filled with 4th rate code monkies who would love to make their mark on the world. But its hard to prove the negative here as there is huge investment in this 'make beleive' article by persons that want it to be 'made real'.

RE-NOMINATE FOR DELETE — Preceding unsigned comment added by 94.118.0.0 (talk) 20:07, 8 June 2015 (UTC)


 * Google currently shows 292,000 hits, so it seem that the term is reasonably commonplace. Reify-tech (talk) 20:12, 8 June 2015 (UTC)


 * Words 'thats a fact' prove literary nothing. And now, in November 2020, Google Books search https://www.google.com/search?tbm=bks&q=%22code+smell%22& finds about 90 books. I have not checked each of them, but at least the first ten, spanning years 2005–2016, present excerpts with that exact phrase in the search results page. Apparently, it wasn't just the page authors' push to 'make it real'. CiaPan (talk) 11:29, 4 November 2020 (UTC)


 * I never saw this wiki page until today when I was linking to it, and I have used the term (and have heard it used) many times. It's the best term I know of to describe a wide variety of potential hidden problems under what appears to be working code. Maybe I'm just a 4th rate code monkey, but thats [sic] a fact. Fool4jesus (talk) 20:42, 5 February 2021 (UTC)


 * Agree with Proposed_deletion. 24.92.248.18 (talk) 03:48, 20 September 2022 (UTC)

Bulleted list in lead section contains contradiction and contains false statement
I edited the bulleted list summarizing the empirical study in the lead section to correct a contradiction, but my edit was reversed by User:Sminthopsis84 without explanation.

The first two bullets of the list contain these two mutually contradictory statements:
 * "most bad smells affecting a piece of code are already present since its creation"
 * "most code smells are introduced while adding new features and enhancing existing ones"

These two statements cannot both be correct. When I referred to the cited study linked through the footnote, I found that it never claims that "most code smells are introduced while adding new features and enhancing existing ones". I made a change that is more consistent with the study and eliminates the contraction. I invite User:Sminthopsis84 to respond to this criticism with an explanation as to why the above criticism is invalid. To Serve Man (talk) 22:21, 3 March 2016 (UTC)


 * Okay, I see now that I misread the change, and have restored it. It is not true that I did not leave an explanation. Sminthopsis84 (talk) 01:18, 4 March 2016 (UTC)