Overview

A Checkstyle configuration specifies which modules to plug in and apply to Java source files. Modules are structured in a tree whose root is the Checker module. The next level of modules contains:

• FileSetChecks - modules that take a set of input files and fire error messages.
• Filters - modules that filter audit events, including error messages, for acceptance.
• AuditListeners - modules that report accepted events.

Many checks are submodules of the TreeWalker FileSetCheck module. The TreeWalker operates by separately transforming each of the Java source files into an abstract syntax tree and then handing the result over to each of its submodules which in turn have a look at certain aspects of the tree.

Checkstyle obtains a configuration from an XML document whose elements specify the configuration's hierarchy of modules and their properties. You provide a file that contains the configuration document when you invoke Checkstyle at the command line, and when you run a Checkstyle task in ant. The documentation directory of the Checkstyle distribution contains a sample configuration file sun_checks.xml which configures Checkstyle to check for the Sun coding conventions.

Modules

A module element in the configuration XML document specifies a module identified by the element's name attribute.

Here is a fragment of a typical configuration document:

<module name="Checker">
    <module name="JavadocPackage"/>
    <module name="TreeWalker">
        <module name="AvoidStarImport"/>
        <module name="ConstantName"/>
        <module name="EmptyBlock"/>
    </module>
</module>
      

In this configuration:

• Root module Checker has child FileSetChecks JavadocPackage and TreeWalker. (Module JavadocPackage checks that all packages have package documentation.)
• Module TreeWalker has submodules AvoidStarImport, ConstantName, and EmptyBlock. (Modules AvoidStarImport, ConstantName, and EmptyBlock check that a Java source file has no star imports, has valid constant names, and has no empty blocks, respectively.)

For each configuration module, Checkstyle loads a class identified by the name attribute of the module. There are several rules for loading a module's class:

1. Load a class directly according to a package-qualified name, such as loading class com.puppycrawl.tools.checkstyle.TreeWalker for element:

   <module name="com.puppycrawl.tools.checkstyle.TreeWalker"/>
             

   This is useful for plugging third-party modules into a configuration.
2. Load a class of a pre-specified package, such as loading class com.puppycrawl.tools.checkstyle.checks.AvoidStarImport for element

   <module name="AvoidStarImport"/>
             

   Checkstyle applies packages com.puppycrawl.tools.checkstyle, com.puppycrawl.tools.checkstyle.filters, and com.puppycrawl.tools.checkstyle.checks and its sub-packages (only those included in the Checkstyle distribution). You can specify other packages in a package names XML document when you invoke Checkstyle at the command line, and when you run a Checkstyle task in ant.
3. Apply the above rules to name concatenated with "Check", such as loading class com.puppycrawl.tools.checkstyle.checks.ConstantNameCheck for element

   <module name="ConstantName"/>
             

Properties

Properties of a module control how the module performs its task. Each module property has a default value, and you are not required to define a property in the configuration document if the default value is satisfactory. To assign a non-default value to a module's property, define a child property element of the module element in the configuration XML document. Also provide appropriate name and value attributes for the property element. For example, property max of module MethodLength specifies the maximum allowable number of lines in a method or constructor, and has default value 150. Here is a configuration of module MethodLength so that the check reports methods and constructors with more than 60 lines:

<module name="MethodLength">
    <property name="max" value="60"/>
</module>
      

Command line properties and ant Checkstyle task properties apply to the root Checker module. Also, properties are inherited in the module hierarchy. These features make it easy to define one property value that applies to many modules. For example, the following configuration fragment specifies that a tabWidth of 4 applies to TreeWalker and its submodules:

<module name="Checker">
    <module name="JavadocPackage"/>
    <module name="TreeWalker">
        <property name="tabWidth" value="4"/>
        <module name="AvoidStarImport"/>
        <module name="ConstantName"/>
        ...
    </module>
</module>
      

The value of a module property can be specified through property expansion with the ${property_name} notation, where property_name is a command line property or an ant Checkstyle task property. For example, the following configuration document element gives property headerFile the value of command line property checkstyle.header.file:

<module name="Header">
    <property name="headerFile" value="${checkstyle.header.file}"/>
</module>
      

You can use property expansion to re-specify a module property value without changing the configuration document.

The property element provides an optional default attribute which is used when a property in the value cannot be resolved. For example this configuration snippet from a central configuration file checks that methods have javadoc, but allows individual projects to override the severity by specifying their desired value in the command line property checkstyle.javadoc.severity:

<module name="JavadocMethod">
  <property name="severity"
               value="${checkstyle.javadoc.severity}"
               default="error"/>
</module>
      

This feature is a great help when setting up a centralized configuration file (e.g. one file for the whole company) to lower configuration maintenance costs. Projects that are happy with the default can simply use that configuration file as is, but individual projects with special needs have the flexibility to adjust a few settings to fit their needs without having to copy and maintain the whole configuration.

You can find information about property types on Property Types page.

Checker

All configurations have root module Checker. Checker contains:

• FileSetCheck children: modules that check sets of files.
• Filter children: modules that filter audit events.
• AuditListener children: modules that report filtered events.

Checker also defines properties that are inherited by all other modules of a configuration.

<module name="Checker">
    <property name="basedir" value="src/checkstyle"/>
    <property name="cacheFile" value="target/cachefile"/>
    <property name="localeCountry" value="DE"/>
    <property name="localeLanguage" value="de"/>
    <module name="JavadocPackage"/>
    <module name="TreeWalker">
        ...
    </module>
</module>
      

<module name="Checker">
    <property name="charset" value="UTF-8"/>
    ...
</module>
      

<module name="Checker">
    <property name="fileExtensions" value="java, xml, properties"/>
    ...
</module>
      

<module name="Checker">
    <property name="fileExtensions" value="null"/>
    ...
</module>
      

<module name="Checker">
    <property name="fileExtensions" value=""/>
    ...
</module>
      

TreeWalker

FileSetCheck TreeWalker checks individual Java source files and defines properties that are applicable to checking such files.

<module name="Checker">
    <module name="TreeWalker">
        <property name="tabWidth" value="4"/>
        ...
    </module>
</module>
      

<module name="Checker">
    <module name="TreeWalker">
        <property name="fileExtensions" value="java,ejb,jpf"/>
        ...
    </module>
</module>
      

<module name="TreeWalker">
    <property name="fileExtensions" value="java"/>
    ...
</module>
      

<module name="TreeWalker">
    <property name="fileExtensions" value="null"/>
    ...
</module>
      

<module name="TreeWalker">
    <property name="fileExtensions" value=""/>
    ...
</module>
      

TreeWalker Checks

The TreeWalker module creates a syntax tree for a Java source file and invokes its submodules, called Checks, during a walk, or traversal, of the nodes of the tree. Every node of the syntax tree has a token. A visit to a node during the traversal triggers all Checks that are configured for its token. For example, if Check MethodLength has been configured as a submodule of TreeWalker, then a visit to a node with a method or a constructor definition token triggers MethodLength to check the number of lines of the node's code block.

Some Checks, such as FileLength and LineLength, apply directly to the source file and do not involve tokens of the syntax tree. Other Checks are associated with configurable sets of tokens that trigger the Checks. For example, this element configures Check MethodLength:

<module name="MethodLength"/>
      

The default token set for MethodLength is {METHOD_DEF, CTOR_DEF}, method definition and constructor definition tokens, so TreeWalker invokes MethodLength whenever it visits a node with a METHOD_DEF or a CTOR_DEF token.

You specify the trigger tokens for a Check with property tokens. The value of tokens is a list that denotes a subset of the Check's tokens, as in the following element that configures Check MethodLength to check the number of lines of methods only:

<module name="MethodLength">
    <property name="tokens" value="METHOD_DEF"/>
</module>
      

To apply particular properties to different subsets of tokens for a Check, repeat the Check. For example, to check that the length of each method is at most 150 lines (the default value of MethodLength property max) and the length of each constructor is at most 60 lines, include the following in the TreeWalker configuration:

<module name="MethodLength">
    <property name="tokens" value="METHOD_DEF"/>
</module>
<module name="MethodLength">
    <property name="tokens" value="CTOR_DEF"/>
    <property name="max" value="60"/>
</module>
      

Configurations of the Checks are specified in the pages under here.

Severity

Each check has a severity property that a Checkstyle audit assigns to all violations of the check. The default severity level of a check is error.

You can use the severity property to control the output of the plain formatter for the command line tool and the ANT task. The plain formatter does not report violations with severity level ignore, and notes violations with severity level warning. For example, according to the following configuration fragment, the plain formatter outputs warnings for translation violations:

<module name="Translation">
    <property name="severity" value="warning"/>
</module>
      

The XML formatter reports the severity level of every violation as an attribute of the violation's error element.

Custom messages

As of Checkstyle 5 all checks can be configured to report custom, configuration specific messages instead of the Checkstyle default messages. This can be useful in cases where the check message should reference corresponding sections in a coding style document or the default is too generic for developers to understand.

An example usage is:

<module name="MemberName">
    <property name="format" value="^m[a-zA-Z0-9]*$"/>
    <message key="name.invalidPattern"
             value="Member ''{0}'' must start with a lowercase ''m'' (checked pattern ''{1}'')."
             />
</module>
      

Each check configuration element can have zero or more message elements. Every check uses one or more distinct message keys to log violations. If you want to customize a certain message you need to specify the message key in the key attribute of the message element.

The value attribute specifies the custom message pattern, as shown in the example above. Placeholders used in the default message can also be used in the custom message. Note that the message pattern must be a valid java.text.MessageFormat style pattern, so be careful about curly braces outside a placeholder definition.

The obvious question is how do you know which message keys a Check uses, so that you can override them? You can examine all keys in the check's specific configuration documentation. Each check has a section called 'Error Messages'. This section lists every key the check uses and links to the default message used by checkstyle.

Filters

A Checker module has a set of Filter submodules to filter audit events, including the error messages fired by Checks. A Filter can accept or reject an audit event. If all Filters accept an audit event, then the Checker reports the event. If any Filter rejects an event, then the Checker does not report the event. For more information please visit filters page.

AuditListeners

In addition to an audit reporter for text or XML output, a Checker can have custom AuditListeners that handle audit events. In order to use a custom listener, add a Checker submodule for the listener and its properties. For example, to configure a Checker so that it uses custom listener VerboseListener to print audit messages to a file named "audit.txt", include the following module in the configuration file:

<module name="com.mycompany.listeners.VerboseListener">
    <property name="file" value="audit.txt"/>
</module>
      

Packages

Checkstyle loads a module class according to the name of a module element, and automatically appends pre-specified package prefixes to that name in its search for a loadable class. By default, Checkstyle applies packages com.puppycrawl.tools.checkstyle, com.puppycrawl.tools.checkstyle.filters, and com.puppycrawl.tools.checkstyle.checks as well as any sub-packages of com.puppycrawl.tools.checkstyle.checks that are distributed with Checkstyle.

To specify other packages to apply, create a package names XML document in a file named checkstyle_packages.xml, and provide that file in the root of the .jar containing your custom checks.

Note that the support for providing a package names XML document via command line option or as a attribute of an ant Checkstyle task has been dropped with Checkstyle 5.0.

A package names XML document specifies a list of package names. Here is a sample package names XML document for packages com.puppycrawl.tools.checkstyle and com.puppycrawl.tools.checkstyle.checks:

<checkstyle-packages>
  <package name="com.puppycrawl.tools.checkstyle">
    <package name="checks"/>
  </package>
</checkstyle-packages>
      

Notice that the packages are specified recursively - a child package element is a subpackage of its parent package element.

For example, to incorporate modules from package com.mycompany.checks with Checkstyle modules, create the XML file below and put this file into the root of the jar file which contains your custom check modules. The XML file must be named exactly checkstyle_packages.xml:

<?xml version="1.0" encoding="UTF-8"?>

    <!DOCTYPE checkstyle-packages PUBLIC
    "-//Puppy Crawl//DTD Package Names 1.0//EN"
    "http://www.puppycrawl.com/dtds/packages_1_0.dtd">

<checkstyle-packages>
  <package name="com.mycompany.checks"/>
</checkstyle-packages>
      

Now you can configure a module of package com.mycompany.checks, say com.mycompany.checks.MethodLimitCheck, with a shortened module element in the configuration document:

<module name="MethodLimit"/>
      

XML Structure

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT module (module|property)*>
<!ATTLIST module name NMTOKEN #REQUIRED>

<!ELEMENT property EMPTY>
<!ATTLIST property
        name NMTOKEN #REQUIRED
        value CDATA #REQUIRED
>
      

<!DOCTYPE module PUBLIC
    "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
    "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
      

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT checkstyle-packages (package)*>

<!ELEMENT package (package)*>
<!ATTLIST package name NMTOKEN #REQUIRED>
      

<!DOCTYPE checkstyle-packages PUBLIC
"-//Puppy Crawl//DTD Package Names 1.1//EN"
"http://www.puppycrawl.com/dtds/packages_1_1.dtd">
      

<?xml version="1.0" encoding="UTF-8"?>

<!ELEMENT suppressions (suppress*)>

<!ELEMENT suppress EMPTY>
<!ATTLIST suppress files CDATA #REQUIRED
                   checks CDATA #IMPLIED
                   id CDATA #IMPLIED
                   lines CDATA #IMPLIED
                   columns CDATA #IMPLIED>