One of the most boring parts of a Java project, and one that developers invariably shy away from, is the code review. Checking thousands of lines of somebody else's code for things like block braces, code indenting, Javadoc comments, and naming conventions can be a real pain. To make matters worse, code reviews are typically constrained by unforgiving and tight project schedules. There is never enough time for detailed evaluation of code, so code reviews often become just an exercise in code beautification. Despite the best intent of the reviewer, optimization and logic checking take a back seat.
Java code analyzers ease the pain
In the face of such problems, Java code analyzers are just what the doctor ordered. These tools are meant to automate as much of the code review procedure as possible. The only part of the review that's left to the human reviewer is checking for any flaws in the core logic of the class and identifying possible optimizations. Optimizations (getting rid of unnecessary object instantiation, verifying that database connections are used wisely, and making sure that data is cached wherever possible) can make a big difference in the performance of any code.
I recently undertook a review of various code analyzers. One basic feature I felt was essential was integration with commonly used IDEs like NetBeans, Eclipse, jEdit, and JDeveloper. Some code-checking tools are great at finding errors in code but expect you to use the erroneous line number as a reference and to manually hunt down the error. Such tools are too strenuous to be adopted in projects. Tools integrated with IDEs greatly simplify this process, as the code-checking results are displayed within the IDE being used. You just need to double-click the error to select the corresponding line of code in your Java editor.
What I tried and what worked
Among the tools that I tried, I found three that were sufficiently powerful and that met the IDE support criterion: PMD, Checkstyle, and Jalopy.
PMD and Checkstyle
According to the PMD documentation, the tool checks for the following things in your code:
- Unused local variables
- Empty catch blocks
- Unused parameters
- Empty if statements
- Duplicate import statements
- Unused private methods
- Classes that could be Singletons
- Short/long variable and method names
Checkstyle looks for these things:
- Javadoc comments
- Naming conventions
- Size violations
- White space
- Miscellaneous checks (including some useful checks like unnecessary System.out and printstackTrace)
How they break down
Unlike PMD, Checkstyle can check for Javadoc commenting; however, PMD offers a useful feature called CPD, which checks for copy pasting of code. With PMD, the errors I found most frequently were unused imports, unused private variables, and the occasional duplicate literal. Checkstyle found many more errors. Along with detecting missing Javadoc comments, it caught line width beyond 80 characters, variable names not following conventions, and tab usage instead of spaces, among other things. Both tools give you the option of creating your own rules.
If you want to adopt one of these for your organization, Checkstyle seems a better choice: It checks for most things that company code conventions expect. PMD is a good option if enhancing code quality is your main goal. But if you want to go further and actually have the tool fix your code for you, check out Jalopy.
Jalopy is an easily configurable source code formatter that can detect, and fix, a number of code convention flaws that might appear in Java code. Jalopy is more of a code fixer than a code checker. Jalopy plug-ins are present for most IDEs and, in most cases, they gel quite seamlessly with the IDE. I found Jalopy to be a particularly powerful tool, capable of doing a lot of cool things. For instance, it can fix code indentation, brace alignment, and line wrapping beyond a certain character length, insert relevant Javadoc comments, and sort imports. The best part is that Jalopy is superbly configurable. A simple UI lets you tweak almost anything that Jalopy does; no tweaking with XML configuration files is required.
Don’t waste resources
Instead of struggling through your code reviews and wasting precious resources on work that often doesn’t achieve much, I would recommend going with one of these tools. Once the tools have made code-checking a relatively simple task, you can make code review a regular activity and not something to be done at the end of a project, when deadlines are already making life miserable. The tools also provide integration with Apache Ant, so you could very well run the code checker daily while a build is being taken or when your unit tests are executed. Stay in control of your code and deliver code that you honestly believe is of a high quality.