Maven and checkstyle
Reprinted by the author:
By: 88250
Date: January 1, July 20, 2010
- Maven and checkstyle
- Summary
- Prerequisites
- Example POM
- Encoding Rule Configuration
- List violations
- Javadoc tag
- Naming
- Conclusion
- Further reading
Summary
Checkstyle is a tool that helps Java developers follow coding standards when writing code. It can automatically check the Java code style and save manpower. This document uses a project example to describe Maven-based
The project uses the checkstyle configuration.
Prerequisites
- Maven2
Basic knowledge
- Install maven2
, Netbeans
(Maven2 IDE is also supported ).
- Sample project: http://latke.googlecode.com/
Example POM
Find the following code in POM. xml of the example project (assuming the root directory is/latke:
<Plugin>
<Groupid> org. Apache. Maven. plugins </groupid>
<Artifactid> Maven-checkstyle-plugin </artifactid>
<Version >$ {maven-checkstyle-plugin.version} </version>
<Configuration>
<Configlocation>
$ {Basedir}/etc/beyondtrack_checks.xml
</Configlocation>
....
</Configuration>
....
</Plugin>
Bold indicates the encoding rule configuration file used by checkstyle. This project uses Maven-checkstyle-plugin version 2.5.
Encoding Rule Configuration
Use the text editor to open beyondtrack_checks.xml under the etc directory under the project root directory (/latke. This rule is configured in Sun
Some modifications have been made based on the encoding specifications, and some restrictions have been relaxed, such as ignoring the Packet document check. Some restrictions have also been enhanced, such as using the final keyword to modify local variables.
For more information, see this document.
.
List violations
Javadoc tag
Find in the Rule file:
<Module name = "javadoctype">
<Property name = "authorformat" value = "/s"/>
<Property name = "versionformat"
Value = "/D /. /D /. /D /. /d, [A-Z] + [A-Z] {}/d {},/D "/>
</Module>
This module defines the check rules for Java class and interface javadoc annotations. Assume that the source code of a Java class in this project is as follows:
/**
* This class defines all message model relevant keys.
*
* @ Author <a href = "mailto: DL88250@gmail.com"> LIANG Ding </a>
* @ Version
1.0.0
, Jun 24,201 0
*/
Public abstract class implements acti18nmodel {}
The version of this class is marked in bold, but the version format (/D/./D) is forcibly defined in the Rule file.
) Is 4 bits, so the project will be output (the row number and column number are subject to the actual conditions, the same below ):
Abstracti18nmodel. java: XX: Type javadoc tag @ version must match pattern '/D /. /D /. /D /. /d, [A-Z] + [A-Z] {}/d {},/D/d '.
Naming
Find in the Rule file:
<Module name = "constantname"/>
This module defines a check for constant naming, where the default rule format is used: ^ [A-Z] [A-Z0-9] * (_ [A-Z0-9] +) * $
. When a field is modified by static final, this field is a constant field, and checkstyle checks whether the above naming format is satisfied.
Assume that the source code of a Java class in this project is as follows:
Public final class keys {
Private Static locale defaultlocale;
/**
* Key of action status code.
*/
Public static final string status _
C
Ode = "SC ";
}
The status_code field contains a lowercase letter, which violates the constant naming rules. Therefore, when you build the project, the following output is displayed:
Keys. Java: XX: Name 'status _ Code' must match pattern '^ [A-Z] [A-Z0-9] * (_ [A-Z0-9] +) * $ '.
Conclusion
Checkstyle can unify the Java code style during team programming and improve the code quality. By customizing its check rule configuration, the team can maintain a certain degree of consistency in the Java code style of a specific project.
Further reading
- Maven checkstyle plugin
- Checkstyle