I love hearing that your team is using Agent Ralph.

I’ll see if I can get Agent Ralph updated for the latest R# soon.

Thanks,
Josh

I have found Agent Ralph very useful and my team is using it extensively. Could you please add support to ReSharper 6.x as we have upgraded to ReSharper 6.x?

Thanks and Regards
Ranji

I didn’t realize that there was a exact match following the hashed match. I agree, my false positive concern is misplaced.

I am looking forward to reading your papers.

Josh

It also detects “near miss” clones which you can think of as parameterized code, e.g., if you made a macro out of block of code and replaced well-formed sections, you’d end up with a parameterized clone.

The present (2010) implementation operates somewhat differently than the 1998 paper, but the basic ideas are the same. A 2004 study (published in IEEE Transactions on Software Engineering) by Steve Bellon compared several detectors, and concluded that ours produce the smallest number of false positives, so I think your worry is misplaced.

You’ve observed that matching exact trees is “easy”. In fact, I agree. What isn’t easy is matching inexact trees to produce the near miss clones, and making this work at the 2 million line scale for multiple programming languages.

You can find a number of examples of clone detection runs on different languages at the website.

– IDB

I read your paper, though I have not tried out your implementation. If I remember correctly, the high level view of the algorithm was to compute a hash on the ASTs and sub-ASTs, and then compare hashes for clone detection. I think that one advantage to my approach is that when a clone is reported there is a higher degree of certainty that it is valid. (I think like 100% certainty, though I haven’t proven that or anything.) The ‘fuzzy hash’ idea where the hash calculation handles some constructs differently in an effort to detect near miss clones (like ignoring small sub trees for example) seems like it would generate false positives. For my tool false positives aren’t acceptable as I want to automate the clone repair. Of course, a hash based implementation would be a lot faster. I am dealing with the kind of poor algorithmic complexity you mention in your paper, like O(n^3) and worse sometimes.

I would like to read more about how you automated the repair of the clones. Do you talk about that in one of the other papers? I’ve only read the one.

Thanks for the comment,
Josh

On performance: I opened a ~75 line method (the extract method implementation itself, ironically) and it tanked. I left it to spin and went to bed. After about 7 hours it still wasn’t done. I realized I needed a heuristic. So, I modified the algorithm to only consider extraction windows whose size matches an existing method. For example, don’t bother extracting a three statement block if you’re just going to compare the result to a four statement block. This made scanning the big methods practical. I think it changes the algorithmic complexity to be linear, maybe even sub linear.

On robustifying: My philosophy in this project is that I want to detect clones by proving two pieces of code functionally equivalent. To prove that, I apply a series of strict refactorings, where strict means the refactored result has not changed it’s inputs, outputs, or side effects. If the code can be safely coerced to a perfect match of some other code then they are clones. So to answer your question, the way I would solve your example is not by “relaxing” the comparison to say, disregard literal input values. Instead I would apply an Introduce Local Variable refactoring to the literals. Subsequent extract methods would exclude said variable definitions producing ASTs that when compared now do not fail due to different literal inputs.

It’s a different way of accomplishing the same thing, but I think it has some advantages. One is that refactoring implementations are external, sort of like plug-ins. I can implement a new one (or accept someone else’s) and just add it right to the list, improving the whole system without having to touch the core code.

You point out that this won’t really scale well, and I can see why. Have you looked at any real-life performance results? How large can the source file be for the refactoring to run in some bearable-amount of time?

Do you have plans for extending this refactoring to be more robust? It might be neat to extract clones which only differ by input value, so you could extract things like MyClone(100), MyClose(200). I imagine this would add some additional complexity to your AST representation..