Static Code Analysis

Static code analysis is a powerful tool for identifying problems in source code, problems like unused variables, incorrect use of static variables, overly nested code, etc. I use Eclipse for the most part these days, so I decided to investigate which tools work better for me with Eclipse.

1. Eclipse SDK

The Eclipse Java perspective itself is very good in this area. The default set is good, and it finds problems as it goes. The only thing I don't like is that the "fix problems like this" feature does not work. Maybe in 3.3.... The configurability is excellent too, with the ability to set flagging at the error, warning, or "none" levels, either on a per-project or per-workspace level.

2. FindBugs

Findbugs is nice too. The integration with Eclipse has been thoughtfully done. The problems show up in the same place that the ones that Eclipse itself does. Also, the default set of problems found are all things I agree with. As a test, I set it loose on the SaTScan code I've been working on, and it found 4 problems, all of which I agree with. For example, the pattern "this.getClass().getResource" is a bad one, because sub-classes will get "unexpected behavior"

3. Lint4J

Lint. The granddaddy of them all. Lint4J is a worthy Java version. It finds a different set of potential problems than FindBugs does. It has the same strenghts that FindBugs does, in that it is conservative, and integrated with the Eclipse "problems" mechanism. It's flaw is that it is maybe too conservative. I find this one mostly useful when cleaning up some "foriegn" code.

4. PMD

This one has a special place in my heart because I contributed to it some years ago (the Beans rules). However, I don't think I'll be using this one in Eclise too much. Why? First of all, it finds WAY TOO MANY problems. With the default set, the SaTScan code that FindBugs found 4 problems in, and Lint4J none, PMD found 68. That's in 229 lines of code, including white space and curly brases. Too many.... Even the line "public static void main(String[] args) {" got flagged, because I was not using the "args" variable. I'm sure with some effort I could configure it to do something I liked, but who has time? Also, the Eclipse integration uses its own perspecive. It's kind of cool, but in practice, it's disruptive. The first rule for a plug-in "don't get in my way!" I noted that the Eclipse plug-in was done by someone other than the PMD author. PMD has the most potential for fine control over coding practices, it might be good in some corporate shop where uniform code quality is important, maybe with selected rules integrated into the build process.