Automated code reviews with Checkstyle, Part 2

Stop rule-breaking code before it enters your code base

By ShriKant Vashishtha and Abhishek Gupta, JavaWorld.com, 11/25/08

Checkstyle makes it easy to automate code reviews once the code has been committed, but wouldn't it be better if programming errors never made it that far? In this second half of "Automated code reviews with Checkstyle," authors ShriKant Vashishtha and Abhishek Gupta show you how to be proactive about code quality. Find out how to use Checkstyle's custom rules to enforce code standards and catch mistakes -- long before code is committed to your code base. Level: Intermediate

In the first half of this article, you learned how easy it is to create and use custom Checkstyle rules for automated code reviews. The solution we presented in that article was only partial, however: it offers custom rules but no mechanism for keeping faulty code out of your code base. In this article we'll show you how to use Checkstyle to proactively enforce code standards, first by catching them as they're written, and then by catching them at the source repository level. Proactively enforcing code standards at these levels will make code reviews less time-consuming, and will allow your team to concentrate on the finer points of code quality.

The first example is based on a custom Eclipse plugin, which displays a warning when it spots a problematic line of code. The second example, especially good for teams not using Eclipse, shows you how to use Subversion's pre-commit hook to check for code violations. This approach bars developers from committing source code with un-fixed violations.

We'll start with building the custom Eclipse plugin to handle custom checks. If you're not familiar with creating custom rules in Checkstyle, you should probably read the first half of this article before continuing. If you're not using the Eclipse IDE, skip ahead to learn about enforcing code standards with Subversion's pre-commit hook.

Build an Eclipse plugin to enforce custom rules

The standard eclipse-cs Eclipse plugin works well for Checkstyle's built-in checks, but you'll need to create your own plugin to handle custom checks. For the sake of demonstration, we'll use IllegalExceptionThrowsCheck, the simpler custom check from the first half of this article. The sample code for this article contains the source code for IllegalExceptionThrowsCheck. Note that we assume familiarity with the Eclipse development environment and plugins.

Before you begin, you have the option to provide metadata in the form of a checkstyle-metadata.xml file for the custom checks; this makes it easier to use the capabilities of the Eclipse plugin's configuration editor. Place this file into the packages where your check classes reside. You'll be able to configure your custom check with the editor just as you can any standard Checkstyle module. Listing 1 contains the sample configuration for your custom check, IllegalExceptionThrowsCheck.

Listing 1. Changes in plugin.xml for custom checks

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE checkstyle-metadata PUBLIC
"-//eclipse-cs//DTD Check Metadata 1.0//EN"
"http://eclipse-cs.sourceforge.net/dtds/checkstyle-metadata_1_0.dtd">
<checkstyle-metadata>
  <rule-group-metadata
    name="Custom Checks"
      priority="900">
      <rule-metadata name="Illegal Exception Throw"
        internal-name="IllegalExceptionThrowsCheck"
        parent="TreeWalker">
          <alternative-name
            internal-name="com.abc.checkstyle.check. IllegalExceptionThrowsCheck" />
          <description></description>
          <property-metadata name="illegalExceptionsInThrows" 
            datatype="String"
            default-value="Exception,java.lang.Exception">
            <description></description>
          </property-metadata>
      </rule-metadata>
  </rule-group-metadata>
</checkstyle-metadata>

The root <checkstyle-metadata> tag can contain the metadata of multiple rule groups, each with a <rule-group-metadata> tag. The name attribute is used as the display name, and the priority attribute influences the order in which the groups appear in the configuration editor.