How is it that static analysis is still a best kept secret while so much lips service is paid to code reviews? We have long since understood that boring repetitive jobs should be left for the machines, but when it comes to code inspection there seems to be a mental block. Humans hold the advantage when reviewing architecture, use of design patterns and code organization, but a machine will find when a known null value is dereferenced 100% of the time and that can hardly be said for even the OCD coders I know. Therefore, I present the top five static analysis tools for Eclipse. While you might not have the delight of working on a project running continuous integration with a full unit test suite, code coverage, and static analysis, you can at least run your own private versions and rest comfortably knowing you’ve done your best.
I assume at the very least that you’ve written some unit tests in Junit or maybe TestNG, the next step is to see if you are actually testing enough of your code. Code coverage has saved me a number of times when I’ve been a little lax in my TDD discipline. Having written some code, followed by some tests, its very easy to forget that one code branch and fail to exercise it; EclEmma to the rescue. EclEmma installs a Coverage mode right next to the run and debug modes that are standard to Eclipse. Simply run your unit test with the Coverage mode and bang, your code shows up bright green, yellow or red, letting you quickly know where you forgot a test or two.
The next level of analysis comes from the well respected FindBugs tool. After installing the plugin, FindBugs inspects the actual .class files of your compiled code for well know bugs and other suspicious behavior. I’m constantly surprised at the lack of false positives and overall quality of the bugs it finds, from comparing strings with ==, to failing to close resources, and more, its spot on.
Code Complexity Analysis
Next in my list of favorites is complexity analysis. These metrics, from simple lines of code in a method to the lesser know but more powerful Cyclomatic Complexity and Efferent Coupling, are the closest thing to a “stinky code” test that software engineering has come up with. If you strive for loose coupling and DRY code, then EclipseMetrics is right up your alley. Once it is installed you will see warnings where your methods are overly long or complex, or your classes are poorly organized. Let the OCD run wild.
Dependancies are one of those things that can go unnoticed until they bite you in the rear. Once circular dependancies creep in it can become incredibly hard to break apart and modularize your code. This might not seem important in a small to medium sized project but once a project scales up, the need to break it apart becomes critical and keeping your ducks in a line from the get go makes life that much easier. For this task we employ JDepend4Eclipse.
Source Code Analysis
Finally we come to PMD. This is the twin brother of FindBugs. Where FindBugs checks the .class file, PMD checks the .java file. There is a lot of overlap here but you can find some interesting things like unused code that javac might have optimized away in the .class file.