RefactoringNoses

See also www.program-transformation.org/re/

Does anyone know of anything similar for Java code?

I also found some articles (IvanM cited:) at citeseer. The most easily understood one is:

citeseer.nj.nec.com/kataoka01automated.html

so some people are definitely researching this.. (NeilThorne)

• JLint artho.com/jlint/ checks for certain types of smell
• Same sourceforge.net/projects/same/ checks for code duplication
• An old code duplication detector www.iam.unibe.ch/~rieger/duploc/index.html

I've been re-reading the RefactoringBook?, specifically with reference to the DuplicatedCode? smell, which is "number one in the stink parade". Not used Same, but started thinking about writing a program which did some lexical analysis of Java code to form the basis of an automatic nose.

This is the sort of thing that I would have liked to use JXR2 for as it allows the conversion of Java code into an xml tree which you can apply xslt to. This means that you can describe smells as xpath expressions. just another stupid idea -- JeffMartin

Supports of Eclipse may cry "but all the facilities exist here already". I'd have to talk to people who've got first hand experience of the API to be sure if it offers what we need.

If using Eclipse turns out not to be an option, I've located JavaCC? www.webgain.com/products/java_cc/ and JTB www.cs.purdue.edu/jtb/ which together can be used to take a raw .java file and allow inspection of method names, parameters and the like.

DuplicatedCode? could (naively) be located by comparing statements in some kind of normalised form (I don't know if Same is this advanced) within the same class. Sibling classes could also be inspected. FeatureEnvy? and LongParameterList? should be pretty easy to sniff out too.

I'd hope to use this to determine some sort of quantative measure of how much code stinks, which would be invaluable in discussions of XP and as a barometer for when refactoring is overdue. (TimG)

I had an idea similar to this after OT2001: attempt to combine code metrics into code smells. The approach that occurred to me was to use the method you use with training some AI systems: get some 'experts' (do we know any experts :-) ? ) to classify code according to "smelliness" and then correlate the smelliness with standard metrics applied to the code. The point of the exercise being to discover several things

• Do the experts agree on what is smelly? If not then then refactoring is irredemably an art.
• Do the metrics measure anything that we care about? Maybe usefull information is buried in metrics but maybe not and we need new ones.
• If we can synthesise measures of code smells out of metrics then producing a refactoring tool which could give you something equivalent to a green or red bar would be possible: this would be a big bonus towards driving refactoring in inexperienced teams I think. ChrisCottee (recently returned to the country and with time on his hands)