Java code review tools
Post date: Mar 31, 2013 3:33:22 PM
One of the reason behind failing projects is the fact that people don't do lot of reviews and when they find bugs in system testing phase just jump to code review. At this time it is not possible to fix all those issues in code.
People may think that what is impact of comments or naming conventions but poor code clarity, no comments are the reasons why at later stage even people who wrote the code can not understand code written by themselves and if some one else is working on the code written by others then it is a serious issue.
Advantages of code review tools
Tools not only review basic standards and conventions but they can also validate your design decisions whether implemented in code or not. Issues important for performance and memory can be caught through tools.
Most important is that full coverage of code review can only be possible in a big project and it saves your money too. If you have 800 Java files in your project you can understand manual review even if done for month can not cover 100% code. But tool takes hardly 10 to 15 minutes to review 700 Java files.
Tools available
Although many tools are there in the market for Java Code Review but I will mention only few which either I evaluated or got feedback from my teams, other folks.
Following is the list of Java Code Review Tools:-
Check Style
Jalopy (It is a source code beautifier not a code review tool.)
I would like to mention here that selection of tool suitable for you is important but more important is use of tool and implementation of code review process.
Different tools have different advantages and are more suitable for specific use.
Hammurapi
1. Best thing about hammurapi is no dependency on any IDE and can be run as Ant task from any IDE.
2. Another very useful feature from project management point of view is that results of review are stored in a database and published through web application. This way whole project team and project manager can see the results and multiple runs of the project can be compared.
3. There is no requirement to compile it for review. To review code you need source files only not all the dependency libraries. It makes reviewer's life simple.
4. Time taken in a review is also not too high. With hammurapi version run on P-IV machine 800 it takes 11 minutes for review. This time may vary depending upon machine configuration. As per my experience its performance is good.
5. It provides review reports in two ways:- 1. Summary of the violations. 2. Individual code file with all violations on that code file. Here with hammurapi a developer can see all the violations on a source file written by him and by clicking on violation can directly go to the section of the html report (having javasource embedded) to see which piece of code is having problem.
6. In later versions of Hammurapi eclipse plugin is available only for development purposese but for commercial you it requires subscription (fee).
PMD
1. PMD is also a powerful tool and much talked about tool for Java code review.
2. Eclipse plugin is available so tool can be used from within IDE. It may help developers better by allowing them to see the violations on IDE and going directly to actual source like where problem is.
3. Web report is not at all available through a database store so you can not have results stored in a database to be compared later on.
4. You can generate off line html page of review report but source is not linked to it. You will have to use some tool to convert your java source files to html. Again here is a problem:- review report generated by PMD will have hyper links to the html of source but you can not navigate to source html by clicking on report likes because generated html from source will have extension .java.html
Solution:- You can use glean with Java2HTML to generate PMD report along with generation of source HTML. This way above mentioned problem can be avoided.
5. In PMD you can write your own rules either in Java or using XPath expression.
Both the tools provide similar default rules and new rules can be created.
With my experience hammurapi has one great advantage and that is:- results are stored in a database. Another good thing is it comes bundled with everything, only you need to do is run the installation. One thing that may not suite you in longer run is that its eclipse plugin for commerical use is licenced and you will have to pay for it. For some new review rules also they can charge but it was a plan only till last update I had.
PMD can better help developers in IDE because eclipse and other IDE plugins are freely available. If you are using gleen along with Java2HTML pages and you can take some pain to configure glean properties (feedback) file then PMD is most rich in terms of more rules available, ease of rules creation. Even results can be deployed in tomcat or any other java web container using an Ant task. See my post to see how it all can be done.
Check Style
Historically it was a code layout checker but with new versions it can check many aspects of Java code. There are standard and optional checks available. Plugins written by third parties for Eclipse/WSAD, NetBeans, Borland JBuilder, IntelliJ Idea and few other IDE's are available.
Jalopy
It is a source code beautifier not a code review tool. Even if it is not a code review tool I have listed it here to clarify this fact. Plugins for Eclipse, JDeveloper, JEdit are available.
Its commericial version is also available with more features.
Strategy for code review
Clearcut strategy and its implementation is most importnat for code reviews otherwise doing them is waste of time. Following things should be kept in mind:-
1. Plan for reviews. Identify reviews as a task in your project plan.
2. Keep practical time duration and effort for review and issue closure activity.
3. Setup code review tool early in the project life cycle. Before start of coding tool should be setup.
4. Let your developers know what are the things to keep in mind, means rules to take care of so that they should minimize injection of more violations. Also give them training of tool.
5. Ask developers to run the tool frequently (e.g. 2 times a day). Also run tool on complete code and publish it on central machine. For it you should setup a project website where along with code review results other important documents can be stored (e.g. html version of project plan, published design model etc). In most of the companies people don't have modeling tool license for every developer so publishing model as html is a good option.
6. Most important is closer of violations and it should be done on daily basis only then people will stop injecting more bugs in future.