
When and Why Your Code Starts to Smell Bad [pdf] - adamnemecek
http://www.cs.wm.edu/~denys/pubs/ICSE%2715-BadSmells-CRC.pdf
======
mtrn
A try at a tldr:

> 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.

~~~
dikaiosune
They also note that the majority of smells (as defined by their static
analysis suite) are introduced when adding new features or enhancing existing
ones, which is a bit different from the usual "maintenance creates smells"
adage. Less than 20% of what they defined as smells were introduced by bug
fixes, something I think of more when I think of "maintenance." I'm still a
bit skeptical of the methods, but an interesting read.

------
maramono
Very interesting!

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...](http://ortask.com/research-the-effects-
of-test-redundancy-on-your-sut/)

------
jason_s
>if smell_k has been introduced in the commit c_1 where f_j has been added to
the repository, then c_1 is the smell-introducing commit

LOL! I love it, they're trying to quantify this stuff.

~~~
ak39
Yeah. That's where I thought the analysis itself became over-engineered. It's
interesting, but can the concept of code smell be reduced this way?

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.

------
j_m_b
The term "code smell" is just so... cute.

~~~
wwweston
I really dislike the term myself. It's not just cute, it's jargon-y. It's
language that leans away from describing a problem and towards unexplained
pejorative -- and it's a _concept_ that leans away from talking specifically
about what's wrong and towards a vague sense that something deeper _might_ be
wrong.

* "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."

~~~
collyw
Its like saying "you're doing it wrong" without explaining what is better.

