RefactoringNoses

TheNose

See also http://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:

http://citeseer.nj.nec.com/kataoka01automated.html

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

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

I don't know why there are so few downloads of Same; I tried it, it worked fine and I quite like the idea (IvanM) I've started working on a code duplication spotting/removing thing JavaCondenser.

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? http://www.webgain.com/products/java_cc/ and JTB http://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)

I don't disagree (I've never used IDEA) but I'd just like to add that Eclipse does most (all?) of these things as well -- RobertHunter