Rocket Surgery

Sometimes you may find your team continually doing something that you wish they wouldn’t do. For example, you may find them continually hardcoding references to their c: drive in code, when the code eventually needs to run on a Linux box, but they never work on anything but Windows.

When cases like this arise, it’s almost obscenely easy to write a custom PMD rule to do code reviews for you to look for and flag these problems. PMD (pmd.sourceforge.net) is a tool for doing static code analysis and producing XML output files which can be transformed into useful outputs (such as HTML reports) for later perusal. Plug-ins for most major IDEs are also available.

PMD also is extensible by writing new rules. These new rules can be written in two ways: one is by writing Java and extending the PMD framework. This is the harder way. The easy way is by writing XPath expressions that look for nodes over an Abstract Syntax Tree (AST) that PMD constructs for you when it runs. PMD includes a tool called designer that lets you interactively build these rules. Once these rules are built, you can incorporate them into the rulesets that PMD enforces during execution and analysis.

So, going back to our example about hardcoded c: drive references, the following XPath query will find nodes in the AST for any class that has a literal beginning with either c: or C:

//Literal[contains(@Image,'"c:') or contains(@Image,'"C:')]

Looking closely, it will find any any string literal begining with double quote, a ‘c’ (in either case), and a colon.

Consider another scenario. Frequently inexperienced developers will catch execeptions without being entirely sure what to do with them, and will simply print the stack trace. While this is probably ineffective in most cases, it is almost certainly undesirable in JUnit tests. When exceptions occur in JUnit tests, they should either be completely ignored (because they don’t matter), or should perk up to the JUnit test runner to be reported as a test error. Handling exceptions with stack traces in JUnit tests keep the test runner from detecting the error and cause success rates to be inflated.

So, we want a rule to detect printing stack traces in a test case, since we have decided that this is bad. The following rule does the trick:

//ClassOrInterfaceDeclaration[starts-with(@Image,'Test') or ends-with(@Image,'Test')]//Name[ends-with(@Image,'printStackTrace')]

This XPath query looks for classes or interfaces that have names beginning with ‘Test’, and which contain a method invokation ending with ‘printStackTrace’. Note that this rule is not a 100% solution: it does require that JUnit test cases follow a naming convention (which is common in most shops anyway). PMD does have the limitation that its AST does not show the entire class heirarchy of the class under analysis, so determining whether the class is a descendant of another is problematic.

As easy as it is to add rules, anyone who uses PMD to analyze their code owes it to themselves to look into the custom rules capabilities of the tool and start looking for ways to monitor the little idiosyncracies in their shops.

This entry was posted on Wednesday, January 25th, 2006 at 3:00 pm and is filed under Software development.You can follow any responses to this entry through the RSS 2.0 feed.You can leave a response, or trackback from your own site.