Towards Benchmarks
Yesterday (05.05.10) I (dsp) was reminded that we don't have many benchmarks for smell detection available. Here is what I'm currently aware of. All the samples contain bad smells although they are not annotated. … and these projects are small. Still it's worth to make a beginning 
.
- Marting Fowler
- The video store example from his seminal Refactoring book. (The code can be found here)
- He elaborated a longer example that got rejected for the book, but is of course even more interesting as a benchmark for us. (Code1))
- William C. Wake
-
- Serge Demeyer, Filip Van Rysselberghe, Tudor Girba, Jacek Ratzinger, Radu Marinescu, Tom Mens, Bart Du Bois, Dirk Janssens, Stephane Ducasse, Michele Lanza, Matthias Rieger, Harald Gall, Mohammad El-Ramly2): The LAN-simulation: A Refactoring Teaching Example. Principles of Software Evolution, International Workshop on, pp. 123-134, Eighth International Workshop on Principles of Software Evolution (IWPSE'05), 2005.
- Smell: Code duplication → Refactoring: Extract method
- Smell: Feature envy → Refactoring: Move method
-
- Smell: Feature envy → Refactoring: Move method
- Smell: Code duplication → Refactoring: (here) Tease apart Inheritance, Introduce State Pattern
- Smell: Dependency cycle → Refactoring: Introduce Observer Pattern
- Refactoring exercise from our Object Oriented Software Construction lecture, “Rectangle”
- Smell: Feature envy → Extract + move method
- Smell: Comments (in method body telling the “what” not the “why”) → Extract method
- Smell: Code duplication → Extract method
- Smell: Dependency cycle → Extract Interface & Use Super type where possible
- Cohesion-tests - A collection of Java test classes for use in evaluating object-oriented cohesion metrics.
- Desription: “This project provides a collection of Java test classes for use in evaluating object-oriented cohesion metrics. The classes vary in the amounts of connectivity within the classes' members, and in the types of connectivity. These classes should also be useful in evaluating the effectiveness of automated Extract Class refactoring tools.”
- Examples developed/colltected by Keith Cassell.
- Not yet explored further by us.
- Premature Over- Under-design
- Not so few Java programmers tend to create artificial complexity3) in their code. Unfortunately removing this complexity seems to be even harder than removing the standard smells.
- William Woody gives an excellent idea about how this kind of code feels in his blog post "How (not) to write Factorial in Java."
- My (dsp) candidate name for the smells that would detect this artifical complexity is ”Occams razor set”.
- Further Candidates (Not explored further)
- http://www.computer.org/portal/web/csdl/doi/10.1109/WCRE.2009.23 - Reports about God Classes in Open Source projects.
1)
Extracted from the PDF. Made some minor corrections to get it to compile. Permission to publish given by M. Fowler.
2)
The authors propose this example as a benchmark!
3)
They seem to feel “the urge to add complexity because “someday we’ll need it, I just know it!”, or because “it’s not sufficiently flexible enough” or “we need reusability in our code” or (God help us!) because it’s “cool””. See the blog post.
