When and Why Your Code Starts to Smell Bad [pdf]
cs.wm.edu
cs.wm.edu
> Smells are generally introduced by developers when enhancing existing features or implementing new ones. As expected, smells are generally introduced in the last month before issuing a deadline, while there is a considerable number of instances introduced in the first year from the project startup. Finally, developers that introduce smells are generally the owners of the file and they are more prone to introducing smells when they have higher workloads.
I assume that most of the smells that are introduced with new files is due to the experimentation that developers perform to solve the problem at hand. Then once a problem gets solved and the solution implemented, it's time for the next problem, and so on (so no time to "fix the hack", so to speak).
Unfortunately the study only considers the most obvious/high-level aspects for code smells (LOC, coupling). What about processes and tools utilized by developers?
For example, I did a study on the effects of test redundancy on software, and found that the average test suite has 25% redundancy. To me this is a smell and is as important as smells in production code: http://ortask.com/research-the-effects-of-test-redundancy-on...
LOL! I love it, they're trying to quantify this stuff.
The best I can express "code smell" into a reductionist statement is like so:
Code smell is when a given aspect of code contradicts the general purpose, overall ethos or accepted style of the whole program itself.
Leaky abstractions is a good example of this. Improperly normalised tables is another (eg. a calculated totals field in Invoice table).
But then again, a team could have taken the conscious strategy of breaking those rules deliberately. Anti-patterns could be a part of a "pragmatic" development strategy. Code smell detection is not an exact science. It has to be understood in the context of a given program.
* "Oh, man. You've got a long function there. That's a code smell, you know."
* "Long functions often involve keeping track of a lot of state or activity -- and that makes it hard to keep a clear mental model of what it does, making it more likely that you'll make mistakes. See if you can break it down into a series of smaller, simpler functions that are easy to reason about."
Programming culture (today?) is highly egotistical, judgmental, conformist and, paradoxically, divisive.* Ageist too. Such pejoratives are now common in tech.
So we wait for gangrenous functions or putrid variables.
* I mean I don't see cabbage farmers go at each other with the same ferocity and psycho venom about methodologies of growing greener or purple(r) crop. (Ok, I admit my ignorance of the whole cabbage farming culture.)