The documented checkstyle configuration file content (Download checkstyle.xml).
The file references the checkstyle-smartics-suppressions.xml by the property suppressions.file. The file is documented by Checkstyle Suppressions Configuration.
<module name="Checker"> <!-- Allows to pass the reference as a property through eclipse and maven. <suppressionsLocation>checkstyle-standard-suppressions.xml</suppressionsLocation> <propertyExpansion>suppressions.file=${project.build.directory}/checkstyle-suppressions.xml</propertyExpansion> Note that both properties are necessary, since the filter is defined here and this configuration requires a file path. --> <module name="SuppressionFilter"> <property name="file" value="${suppressions.file}"/> </module> <!-- We do not require package.html files since we use package-info.java. <module name="PackageHtml"/> --> <!-- Displaying files on the terminal and cat'ing files is easier with a NL at the end of file. --> <!-- See http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile --> <module name="NewlineAtEndOfFile"> <property name="severity" value="warning"/> </module> <!-- We only allow spaces for indenting. This supports that files have the same structure in every tool without further configuration. --> <module name="FileTabCharacter"/> <module name="FileLength"> <property name="max" value="1500"/> </module> <!-- We want to use CHECKSTYLE:OFF and CHECKSTYLE:ON. --> <module name="SuppressionCommentFilter"/> <!-- package-info.java is required. --> <!-- See http://checkstyle.sourceforge.net/config_javadoc.html#JavadocPackage --> <module name="JavadocPackage"/> <!-- Checks that property files contain the same keys. --> <!-- See http://checkstyle.sf.net/config_misc.html#Translation --> <!-- Commented out because not all property files contain keys and missing keys are often intended. <module name="Translation" /> --> <module name="TreeWalker"> <property name="cacheFile" value="target/checkstyle-cachefile"/> <!-- Relevant for calculating line lengths. --> <property name="tabWidth" value="2"/> <property name="severity" value="warning"/> <!-- We want to use CHECKSTYLE:OFF and CHECKSTYLE:ON. --> <module name="FileContentsHolder"/> <!-- Checks for Naming Conventions. --> <!-- See http://checkstyle.sf.net/config_naming.html --> <!-- smartics justification: --> <!-- Although for technical classes using this naming pattern is a good idea, it restricts the use of good domain names. Therefore we drop this check. <module name="AbstractClassName"> <property name="format" value="^Abstract[A-Z]{1,2}([a-z0-9]+[A-Z]{0,2})*$" /> </module> --> <module name="ConstantName"/> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="LocalFinalVariableName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="LocalVariableName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="MemberName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="MethodName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <module name="PackageName"/> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="ParameterName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="StaticVariableName"> <property name="format" value="^[a-z][A-Z]{0,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- We deem sequences of upper case letters less easily readable than strict camel-cased names. --> <module name="TypeName"> <property name="format" value="^[A-Z]{1,2}([a-z0-9]+[A-Z]{0,2})*$"/> </module> <!-- Checks for Javadoc comments. --> <!-- See http://checkstyle.sf.net/config_javadoc.html --> <!-- smartics justification: --> <!-- We want to have the public interface to be documented with Javadoc. Since we minimize the length of private methods and try to choose expressive names, we do not require to have private methods commented. --> <module name="JavadocMethod"> <property name="scope" value="protected"/> <property name="allowThrowsTagsForSubclasses" value="true"/> </module> <module name="JavadocType"> <!-- We are using many non standard tags like Mojo tags for Maven plugins or tags from the taglet project. Therefore we allow any Javadoc tags. --> <property name="allowUnknownTags" value="true"/> </module> <module name="JavadocVariable"/> <module name="JavadocStyle"> <!-- We do not want to allow empty Javadoc. --> <property name="checkEmptyJavadoc" value="true"/> <!-- We require to have valid HTML in Javadoc. We want to parse the HTML fragments and it is easier with valid HTML. --> <property name="checkHtml" value="true"/> </module> <!-- Checks for imports --> <!-- See http://checkstyle.sf.net/config_imports.html --> <!-- Star imports are less readable and there is a chance for source code compatibility issues. --> <module name="AvoidStarImport"/> <module name="IllegalImport"/> <!-- defaults to sun.* packages --> <!-- Clean up unnecessary to make files easier to read. --> <module name="RedundantImport"/> <module name="UnusedImports"/> <!-- We do not require a specific structure for our imports. We see no practical gain, since we all use the same formatter. --> <!-- <module name="ImportOrder"> --> <!-- <property name="groups" value="java,javax" /> --> <!-- <property name="ordered" value="true" /> --> <!-- <property name="separated" value="true" /> --> <!-- </module> --> <!-- There is no standard package name to control this project independent. --> <!-- <module name="ImportControl"> --> <!-- <property name="file" value="import-control.xml" /> --> <!-- </module> --> <!-- Checks for Size Violations. --> <!-- See http://checkstyle.sf.net/config_sizes.html --> <module name="ExecutableStatementCount"/> <module name="LineLength"> <!-- It is ok if the lines are longer, if required. We will nonetheless request the auto-formatter to use a max length of 80 characters. --> <property name="max" value="120"/> <!-- Ignore Javadoc comments since references to other elements (@see tag, etc.) may get rather long and should not be truncated. --> <property name="ignorePattern" value="^\s*\*\s*[^\s]+.+$"/> </module> <module name="MethodLength"> <!-- We want our methods to be short and doing one thing. Robert Martin's rule of 4 lines (Clean Code p.34) is the goal, but not a strict rule. He states that a method "should hardly ever be 20 lines long". So 40 is currently good enough for us. --> <property name="max" value="40"/> <!-- Empty lines help to structure code and make it clearer. The same goes with inline comments. Therefore they are not counted as lines. --> <property name="countEmpty" value="false"/> </module> <!-- Inner classes are not that easy to read if they are long. They are also lacking an easy way to add documentation. To stress the concise nature of anonymous inner classes. --> <module name="AnonInnerLength"/> <module name="ParameterNumber"> <!-- Robert Martin prefers 0-, 1-, 2- and at maximum 3-argument methods. We are a bit less restrictive and allow 5 arguments. --> <property name="max" value="5"/> </module> <!-- Checks for whitespace - helps to make different formatters conform. --> <!-- See http://checkstyle.sf.net/config_whitespace.html --> <module name="EmptyForInitializerPad"/> <module name="EmptyForIteratorPad"/> <module name="MethodParamPad"/> <module name="NoWhitespaceAfter"> <property name="allowLineBreaks" value="true"/> <property name="severity" value="ignore"/> <property name="tokens" value="ARRAY_INIT, BNOT, DEC, DOT, INC, LNOT, UNARY_MINUS, UNARY_PLUS"/> </module> <module name="NoWhitespaceBefore"> <property name="allowLineBreaks" value="true"/> <property name="severity" value="ignore"/> </module> <module name="OperatorWrap"> <property name="tokens" value="BAND, BOR, BSR, BXOR, COLON, DIV, EQUAL, GE, GT, LAND, LE, LITERAL_INSTANCEOF, LOR, LT, MINUS, MOD, NOT_EQUAL, PLUS, QUESTION, SL, SR, STAR"/> </module> <module name="ParenPad"/> <module name="TypecastParenPad"/> <module name="WhitespaceAfter"> <property name="severity" value="ignore"/> </module> <module name="WhitespaceAround"> <property name="severity" value="ignore"/> </module> <!-- Modifier Checks --> <!-- See http://checkstyle.sf.net/config_modifier.html --> <!-- A strict modifier order makes source code easier to read. --> <module name="ModifierOrder"/> <!-- DRY: Redundancies should be minimized. --> <module name="RedundantModifier"/> <!-- Checks for blocks - helps to make different formatters conform. --> <!-- See http://checkstyle.sf.net/config_blocks.html --> <module name="EmptyBlock"> <!-- If there is an empty block, we want that there is comment why it is empty. --> <property name="option" value="text"/> </module> <module name="LeftCurly"> <!-- We set the brace on a new line. In case of declared exceptions this often makes the method body more readable. --> <property name="option" value="nl"/> </module> <module name="NeedBraces"/> <module name="RightCurly"> <!-- We want to brace on a new line. --> <property name="option" value="alone"/> </module> <!-- Remove useless blocks. --> <module name="AvoidNestedBlocks"/> <!-- Checks for common coding problems --> <!-- See http://checkstyle.sf.net/config_coding.html --> <module name="AvoidInlineConditionals"> <property name="severity" value="ignore"/> </module> <module name="CovariantEquals"/> <module name="EmptyStatement"/> <module name="EqualsHashCode"/> <module name="FinalLocalVariable"> <property name="tokens" value="VARIABLE_DEF,PARAMETER_DEF"/> </module> <!-- Hiding a field is not a real problem in modern IDEs since the members of a class are highlighted and there are sometimes reasons for naming a local variable like a field it corresponds to. <module name="HiddenField"> <property name="tokens" value="VARIABLE_DEF" /> <property name="ignoreConstructorParameter" value="true" /> <property name="ignoreSetter" value="true" /> </module> --> <module name="IllegalInstantiation"/> <module name="InnerAssignment"/> <module name="MagicNumber"> <property name="ignoreNumbers" value="-1,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,32,37,42,64,128,256,512,1024,2048,4096,8192"/> </module> <!-- Try to be explicit where possible. --> <module name="MissingSwitchDefault"/> <module name="ModifiedControlVariable"/> <!-- We deem exceptions as a valuable documentation. --> <module name="RedundantThrows"> <property name="allowSubclasses" value="true"/> <property name="allowUnchecked" value="true"/> </module> <!-- Hints to simplify code to make it more readable. --> <module name="SimplifyBooleanExpression"/> <module name="SimplifyBooleanReturn"/> <!-- More often an error than a conscious decision. --> <module name="StringLiteralEquality"/> <!-- Currently we still use the check for ASCII regexp at the end of this file <module name="StringLiteralEncoding"/> --> <module name="NestedIfDepth"> <property name="max" value="2"/> </module> <module name="NestedTryDepth"> <property name="max" value="2"/> </module> <module name="SuperClone"/> <module name="SuperFinalize"/> <!-- We cannot use this rule since serialVersion fields should always come first. We do not want to order the fields by their access modifier but logically. We would like to use the rule that fields are defined in front of constructors and methods. --> <!-- <module name="DeclarationOrder" /> --> <!-- Although we think that using this rule is generally a good idea, we do not use it since declarations in for-loop-headers are naturally in one line. If there would be an option to allow multiple variable declarations in for-loop-headers we would enforce this rule. --> <!-- <module name="MultipleVariableDeclarations" /> --> <!-- Checks for class design --> <!-- See http://checkstyle.sf.net/config_design.html --> <module name="VisibilityModifier"> <property name="protectedAllowed" value="true"/> </module> <!-- Leads to more expressive code. --> <module name="FinalClass"/> <!-- No public constructor for utility classes. --> <module name="HideUtilityClassConstructor"/> <!-- Do not use interfaces to specify constants only. --> <module name="InterfaceIsType"/> <!-- We prefer immutability for local variables, too. --> <module name="MutableException"/> <!-- Helps to design classes that are easier to use. --> <module name="DesignForExtension"> <property name="severity" value="info"/> </module> <!-- Usually a method should throw only one or two exceptions but may also want to signal one or two runtime exceptions. --> <module name="ThrowsCount"> <property name="max" value="4"/> </module> <!-- Checks for metrics --> <!-- See http://checkstyle.sourceforge.net/config_metrics.html --> <module name="CyclomaticComplexity"> <!-- 8 is the number judged as high complexity. This should start the refactoring. --> <property name="max" value="8"/> </module> <module name="NPathComplexity"/> <module name="JavaNCSS"> <!-- Identical to MethodLength. --> <property name="methodMaximum" value="40"/> <!-- We assume a file length (FileLength) of 1500. Assuming that at least 500 lines are for comments and we allow only one top-level class per file, this number for NCSS seams reasonable. --> <property name="classMaximum" value="1000"/> <!-- We assume a file length (FileLength) of 1500. --> <property name="fileMaximum" value="1500"/> </module> <!-- Miscellaneous other checks. --> <!-- See http://checkstyle.sf.net/config_misc.html --> <module name="ArrayTypeStyle"/> <module name="FinalParameters"> <property name="tokens" value="METHOD_DEF,CTOR_DEF,LITERAL_CATCH"/> </module> <!-- Trailing spaces have no use and are redundant. --> <module name="Regexp"> <property name="format" value="[ \t]+$"/> <property name="illegalPattern" value="true"/> <property name="message" value="Line has trailing spaces."/> </module> <!-- Evade encoding problems by sticking to ASCII. --> <module name="RegexpSinglelineJava"> <property name="format" value="[^\x00-\x7F]"/> <property name="message" value="Line contains non-ASCII char."/> <property name="ignoreComments" value="true"/> </module> <!-- Long literals with upper Ells are easier to read. --> <module name="UpperEll"/> </module> <!-- Evade encoding problems by sticking to ASCII. --> <module name="RegexpSingleline"> <property name="format" value="^[^#].*[^\x00-\x7F]|^[^\x00-\x7F]"/> <property name="message" value="Line contains non-ASCII char."/> <property name="fileExtensions" value=".properties"/> </module> </module>