Agent Ralph‘s front end is a Resharper plug-in.  Any clones detected are passed up to the plug-in which presents them to the user as highlights and quick fixes.  This is how we achieve the automated repair that a modern clone tool needs.  The backend scans source files handed to it by the front end, using the techniques I’ve been blogging about.  Specifically, clones are identified by comparing abstract syntax trees of methods.  The ASTs may be modified by the application of safe refactorings (refactorings that do not change the inputs, outputs, or side effects).  If an AST can be safely coerced until it matches another then we can consider the originals functionally equivalent clones.  This technique will detect clones that would otherwise be overlooked by text based clone finders.

So, here’s the basic case.  Two identical methods:

Note the Resharper squigglies telling us something is up.  Passing the mouse over either method name brings up a tooltip identifying the method as a clone of the other.

Placing the cursor on the method name prompts you with a quick fix…

…and invoking it…

…replaces the body of the clone with a call to the original.  That’s automated clone repair!  An inline method applied to Test1 will complete the removal.

The next methods are identical, but only if a rename local variable refactoring is applied.  And indeed you can see that it is, indicated by the highlighting and quickfix offering.

The last example is one I am particularly proud of.   Here we are detecting a clone that is a block within a larger method.  Methods EmbeddedClone1 and EmbeddedClone2 both contain clones of Test2.

Thus far I’ve restricted myself to using methods as the only unit of comparison.  Doing so made it easier to reason and implement as I worked through ideas.  At some point I realized that I could use an extract method refactoring to create provisional methods from indiscriminate code blocks on the fly.  If the provisional method is a clone then it follows that the original code block is a clone.  In this way I can continue to think and code in terms of methods, yet rely on the extract method refactoring to apply my algorithms to sub-units of method (aka, arbitrary blocks and statements).

Consider this code:

enum MyEnum  { First, Second }
public void Match1(MyEnum e)
{
    if (e.ToString() == "First") { }
}

The problem lies in the condition of the if.  The developer is converting an enum instance to a string for the purposes of a comparison, circumventing type safety.  The primary problem here is that the statement can no longer safely participate in automated refactorings.  For example, if my MyEnum.First is renamed this code will break such that the condition is always false and the body will never execute.  A Find Usages executed on MyEnum.First would not identify this site.  

It also performs worse than the alternatives.  I hesitate to even mention that though because, like most micro performance optimizations, it is only going to matter in uncommon situations like a tight loop or heavy load.

The correct code is this:

if(e == MyEnum.First) { }

The code is now typesafe, fast (it’s a comparison of integers), and refactoring friendly.  And it’s a simple enough fix.  The exact steps are:

1. Scan the enum values list for a member whose name exactly matches the string literal.
2. If found, replace the string literal with a reference to the qualified enum value.

There are some special cases to consider as well.

Here the string is being manipulated before comparing, by calling ToLower().

if(e.ToString().ToLower() == "first") { }

When comparing the result of a ToLower() or ToUpper() call the string constant is single cased, likely with the intention of reducing typos.  I suspect the programmer considered this defensive programming.

Unnecessary complexity begets bugs. When your code base is littered with untyped enum comparisons, this mistake is inevitable:

if(e.ToString().ToLower() == "First") { }

The string constant actually matches the declared enum casing, yet due to the ToLower() call the condition is always false, and the branch is never executed.  This permutation is particularly dangerous as the fix revives a branch that hasn’t been executing. You are eliminating a side effect, and a danger of eliminating side effects is breaking other parts of the system that could be dependent on them.

I have created a tool for automating the correction of untyped enum comparisons.  It’s a Resharper plug-in based quick fix and is available as part of my Agent Ralph project.

Using Agent Ralph to automate a Make Enum Comparison Typesafe code correction.

Currently it only handles the simple case, pictured above.  I hope to correct that deficiency soon.

Thanks to Mark for the great suggestion on a WordPress friendly code syntax highlighter.