The smartics Checkstyle Configuration

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>