Please read Part 1 first.

Automating the Code Review process

You can split the Code Review process into 2 parts: the Low Level part (styling, code duplicate, naming conventions, etc) and the High Level part (architecture, design, business).

Starting from a Coding Standards document, you can easily automate the Low level part of the Code Review process. The automation tools for Code Review will eliminate most of the styling issues, naming conventions, cyclomatic complexity, duplicate code, code coverage, etc. They can’t though detect major design issues, architectural flaws or project specific functionality and this is where the reviewer skills are the most important. I’ll present below the most used tools for Java projects.

Sonar

Each time you talk about Code Quality in the Java world there are very high chances that Sonar is mentioned one way or another in the discussion. Sonar aggregates and displays code quality metrics on a web site allowing drilling down to the source code to view the details of violations. Sonar’s main purpose is to display the metrics in a nice visual manner and uses various plugins to produce these code quality metrics. All the below tools integrate with Maven, Ant and are also available as Eclipse plugins. In order to get the same set of rules for both Sonar and these Eclipse plugins, Sonar publishes the rules for PMD, Checkstyle and Findbugs associated to a specific profile. You can easily link to them from your Eclipse plugins.

Make sure you save all these files as separate XML files: findbugs.xml, checkstyle.xml and pmd.xml.

PMD

PMD is a source code analyzer. It finds unused variables, empty catch blocks, unnecessary object creation, and so forth.

This is the official page: http://pmd.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://pmd.sourceforge.net/pmd-5.0.0/integrations.html#eclipse. Unfortunatelly the Eclipse plugin is not actively supported and some rules are not recognize by it. In order to fix this you must do the following:

• Save the PMD rules from Sonar as an XML file
• Delete the following rules from the file: GuardDebugLogging, GenericsNaming, DontCallThreadRun, AvoidLiteralsInIfCondition, AvoidCatchingGenericException, AvoidLosingExceptionInformation

After doing this you can proceed with the next steps.

• Access Window->Preferences
• Expand PMD
• Click on Rules Configuration

In order to import the Sonar rule set you must do the following:

• First click on the Clear All button in order to remove all the existing rules
• Click on the Import Rules button and select the pmd.xml file you just modified.

An alternative to this is to disable these 6 rules in Sonar and import the ruleset from the published URL. In this way you have all the other rules in sync.

Cobertura

Cobertura is a free Java tool that calculates the percentage of code accessed by tests. It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.

This is the official page: http://cobertura.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://ecobertura.johoop.de/.

Since Sonar 3.2 Cobertura is not the default code coverage tool anymore. JaCoCo is the new default.

Checkstyle

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

This is the official page: http://checkstyle.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse: http://marketplace.eclipse.org/content/checkstyle-plug#.UFggAI3iZSo.

You can configure the Checkstyle Eclipse plugin to use the Sonar published rules as follows:

• Open Window->Preferences->Checkstyle
• Click on New
• Choose Remote Configuration from the Type drop-down
• Enter the permalink URL from Sonar
• Click OK after
• Set the profile as default

Findbugs

Findbugs is a program which uses static analysis to look for bugs in Java code.

This is the official page: http://findbugs.sourceforge.net/.

You can get early warnings about what is wrong with your code by running it directly from eclipse:

http://findbugs.cs.umd.edu/eclipse/

In order to import the Sonar findbugs tules into Eclipse you must do the following:

Choose the findbugs.xml you saved previously and make sure you select the checkbox in order to enable the rules.

JaCoCo

JaCoCo is a free code coverage library for Java, which has been created by the EclEmma team based on the lessons learned from using and integration existing libraries over the last five years.

This is the official page: http://www.eclemma.org/jacoco/.

This is the default code coverage library since Sonar 3.2.

For example, in order to use JaCoCo as the code coverage tool you must include the following properties in your pom file:

<sonar.dynamicAnalysis>true</sonar.dynamicAnalysis>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>

More details here: http://docs.codehaus.org/display/SONAR/Code+Coverage+by+Unit+Tests.

Squid

Squid is part of the Sonar core plugin. More details here:

http://www.sonarsource.org/detect-dead-code-and-calls-to-deprecated-methods-with-sonar-squid/

More about Sonar

Sonar offers out of the box support for Java. No additional configuration is needed.

Sonar will use all the above tools in order to display the Code Quality metrics. This is a high level overview of the Sonar architecture:

Although this article presents the default just some of the plugins, Sonar can be further enhanced in order to display additional information using plugins. Additional plugins can be found here: http://docs.codehaus.org/display/SONAR/Plugin+Library.

You can get the Sonar violations directly into Eclipse. You can find here: http://docs.codehaus.org/display/SONAR/Installing+Sonar+in+Eclipse how to install Sonar for Eclipse and here: http://docs.codehaus.org/display/SONAR/Configuring+Sonar+in+Eclipse how to configure it.

You can also find more info about Sonar for Eclipse here: http://docs.codehaus.org/display/SONAR/Using+Sonar+in+Eclipse.

Monitoring the Code Review process

Until now I presented advises about what to pay attention on when implementing a Code Review process within a project and how you can automate a part of the process, allowing the reviewer to focusing on the important things like design, architecture and business requirements.

What’s the best way to track the review progress: through emails, excel files, just talking or using specialized tools? Although the obvious answer is specialized tools, each team has its own particularities. Usually each team will found its own mechanic when dealing with reviews:

• You can have a rule that no one does a commit until another colleague will review the code
• Each team member will check all the commits when doing an update
• You have a person assigned per day/sprint/iteration that does the code review for everyone
• You do peer code review
• You have a dedicated that does the review team formed only by senior and architects

If you are in an environment where you already use Atlassian tools (JIRA, Confluence, FishEye), the wise choice is Crucible as it integrates with the whole stack of Atlassian products. Currently I think this is the best tool for keeping track of code reviews.

There are also other choices like: Gerrit (dedicated to Git projects) or ReviewBoard.