TheNose

RefactoringNoses | https://xpdeveloper.com/xpdwiki/Wiki.jsp?page=TestingTheNose

Much of what you read about 'code smells' is subjective or relies on the close inspection by a single pair of eyes of potentially large amounts of code... so why not remove some of the subjectivity and have a tool do the close inspection for you? (If it's worth doing then it's worth doing all the time etc etc) -- TimBacon

There is a very closely related dicsussion here at RefactoringNoses plus some papers and implementation ideas. The main user story for me is finding duplicate code. Not just with String.equals() etc. and other white space/tab/end line removing variants.

One metaphor I've been thinking of is that there should be a method on compilation unit called smellsLike(Object) and returns a boolean aswell as the usual equals().

If a compilation unit (say a block A of 4 lines of code) is compared with a similar block B where the only change is that block B uses a super type Person rather that the subtype Man that A uses, then it should return true. I see Noses as an ant task which is run only when a cruisecontrol-like modificationTask observes changes to checked in code -- NeilThorne

Reading the Xp2002 submission (http://www.xp2002.org/atti/Freeman-Simmons--Retrofittingunittests.pdf) by PaulS and SteveF prodded me into action but it is something I have been thinking of for a while now. If anyone has any particular user stories they would like to see as part of the initial release please describe them here...

• OliBye would like to add a view to eclipse that shows me how divergent my code is from the head revision. (I've got a python script that does this badly --JeffMartin)
• • Maybe we could start with a command line query which just asks when was the last time people caught up.
  • Or how many changes they last checked in.
  • • This could be done by patching into the cvs watchers file.
  • Ultimately I'd like to see the base line as a horizontal line, and other lines representing developers and how much code they've changed without checking in.
  • The idea is to have a big display somewhere, so we can see who's coming off the rails. I know this isn't really a code smell, it's more a process smell, but I think the visual feed back it provides could be good for the whole team, with not to much effort to produce the information.

Have you seen the graphs in Kent's TestDrivenDevelopment book? Is this what you're looking for? (TimBacon)

• Duplication of literal strings
• Function size & complexity, class size (number of methods), etc. This can be done with existing code metrics tools.
• Duplicated code fragments (with some fuzzyness)
• Accessing methods or attributes through several levels of indirection, e.g. foo.bar.wibble.doSomething()

The tool I was talking about is jCosmo, a research prototype of a smell detection tool for Java. I've written a research paper on jCosmo and submitted it to a main reverse engineering conference. I'll hear in two weeks (mid july 2002) whether it gets accepted, if so, I'll put the paper online since I rather not have drafts floating around in siteseeer... (NB send me a note if its (long) after that date and I havent updated this page)

The reason I'm a bit hesistant to call it an open source tool is that that will give people the impression that they can start hacking on it. That is a bit difficult since it was written using our main research object the ASF+SDF Meta-Environment, an environment for the generation of language processing tools. The sourses are a combination of syntax definitions in SDF and "transformation rules" in ASF. From the syntax definition we generate GLR parsers, syntax directed editors and pretty-printers. The transformation rules are used for the source code analysis, in this case smell detection. This environment is also open source but there learning curve before one can contribute to a project...

The focus in the paper was on quality assurance and involved visualisation of the code smells so one could do a fast asessment of a large system. One of the other things I would like to do is take the smell detection "front end" and inegrate it with eclipse so you get to see detected smells similar to, for example, compiler errors and warnings.

If you're main interest is finding duplicate code, there has been a lot of research on that in the reverse engineering/program comprehension communities. Look for "clone detection", "copy-paste code", "code replication", etc. Some tools I know of that do Java are CloneDr? (commercial tool, Semantic Designs), Duploc (academic, Rieger), CCFinder (academic, Kamiya) and Covet (academic, Bailey, Mayrand).

Do you have URL's for these? --SteveF url for CloneDr? paper is http://www.semdesigns.com/Products/DMS/index.html -- ChrisCottee

Another tool that could be seen as smell detection tool is RevJava?: a review assistant for Java programs. It's described at http://www.serc.nl/people/florijn/work/designchecking/RevJava.htm It is available for download since may 22, 2002. GertFlorijn (the author of RevJava?) and I have planned to investigate the possibilities of combining our approaches (but that will have to wait until my PhD-thesis is finished).

-- LeonMoonen

Sigh. All these toys. I'll bet they all need at least Java SE 1.3? Anyway, it's hard enough getting our lot to see the advantage of using VAJ to work on Java, versus using VC++ to edit the code and type the compile command out each time. -- KeithB

Wel, RevJava? might be of some help then; it works on compiled Java code. It takes your jar-file or class files and provides both criticisms (smells) and metrics. It does limited analysis of method code, but focuses on the overall program structure and tries to report things that are wrong there. As Leon mentioned, it's available for download. -- GertFlorijn

³host³³date³September 12, 2002³agent³Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0)³TheNose