Most of my work these days is in Java (groan). Well, if you’re going to write in a language with static typing, you might as well make use of it. So I’ve been playing with a few static code analyzers, in order to try and find bugs. I use eclipse, so a plugin is the only sensible way of doing this for me.
This is an eclipse project which aims “integrate a variety of analysis providers”. Whatever. You can set it up to scan your source for “best practice violations”, and it adds a new “analysis view” to your eclipse screen with the results.
On a sample project I ran it over, it found 600+ problems. The vast majority of those were of the form “String literal should be a constant”. Which is not something I happen to 100% agree with.
Some of the problems have a Quick Fix1 option, which is really handy. But not many.
Whilst it found some problems I agreed with, most of the things it found I didn’t agree with. Or didn’t see the reason why, so I ignored it. And that’s the biggest problem with this tool: It never explains why something is bad. You can configure which problems are scanned for (or even add comments to ignore a particular problem for a particular line of code). But the lack of reason deters me from relying on this more.
This is available as an eclipse plugin as well as a standalone tool. Instead of making a new view, it just adds any problems found to the standard “Problems” view, where all the usual compilation errors and warnings are. So it feels like it integrates better.
When it finds a problem, you can right click to get an “explain the problem” view where the exact nature of the problem is spelled out clearly. That rocks.
Not only that, but it’s really good at spotting things that I as a relatively immature java coder just don’t even think about. For example, it found where I was returning objects from accessors. But this is Java—surely that’s what you’re meant to do? No. You should return a copy of an object, because you don’t want somebody else to alter your objects internal state. I’d not have spotted that one in a hurry.
I did have some problems with the eclipse plugin making it a little hard to get rid of the markers in the source code. I’m not sure why, but a little fiddling usually cleared it up where it happened. But that’s a problem with the eclipse integration, not findbugs itself.
The problems it found were generally pretty reasonable, and it didn’t overwhelm me with warnings. But it appears to be easy to make it a lot pickier. In other words, it got the defaults right for me.
This is another one that’s available as both an eclipse plugin and a standalone tool. I’ve only used the eclipse plugin.
Unfortunately, when I first tried it, it switched to the PMD Perspective and brought up a NullPointerException in the “Violations Overview” view (update: looks like bug 1595798). Annoying, but again I suspect it’s the Eclipse integration rather than PMD itself.
The warnings provided by PMD are sensible, but for the first time usage, there are quite a lot (though you can get the outline view to filter by priority). e.g. it complains about direct field access rather than accessors, even though a field is only accessed within a class. I don’t care that much, I can go either way. That said, the explanations about why it’s complaining are excellent. They even include little code samples.
Whilst it claims to offer Quick Fix, it’s grayed out in the menu, so it’s not that useful…
One of the features I really liked is the “cut’n’paste code detection”. Even though it doesn’t integrate properly into eclipse, it just dumps its output into a file. I despise cut’n’paste code.
I’m glad to have the variety of tools. Each of them found different problems. Overall I like like findbugs the best, but PMD is pretty close. There’s no excuse for stupid little bugs…
1 If you haven’t used Quick Fix in eclipse, bring yourself out of the dark age and press Ctrl-1 on a bit of red underlined code. Do this for an hour. Now try and live without it.