checkstyle-checks.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN"
          "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">

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

  <module name="TreeWalker">
    <!-- annotations ======================================================= -->
    <module name="AnnotationUseStyle">
      <property name="elementStyle" value="compact_no_array"/>
      <property name="closingParens" value="never"/>
      <property name="trailingArrayComma" value="never"/>
    </module>
    <module name="MissingDeprecated"/>
    <module name="MissingOverride">
      <property name="javaFiveCompatibility" value="false"/>
    </module>
    <module name="PackageAnnotation"/>
    <!-- unused <module name="SuppressWarnings"/>-->

    <!-- block checks ====================================================== -->
    <!-- Rational: methods should be small enough that nested blocks are never
         needed. -->
    <module name="AvoidNestedBlocks"/>

    <module name="EmptyBlock">
      <property name="option" value="stmt"/>
      <property name="tokens"
                value="LITERAL_CATCH, LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY,
                       LITERAL_IF, LITERAL_FOR, LITERAL_TRY, LITERAL_WHILE,
                       INSTANCE_INIT, STATIC_INIT"/>
    </module>

    <!-- Rationale: Keeping the opening brace on the same line promotes
         concision; additionally, it is the prevailing Java style. -->
    <module name="LeftCurly">
      <property name="option" value="eol"/>
      <property name="maxLineLength" value="80"/>
      <property name="tokens"
                value="CLASS_DEF, CTOR_DEF, INTERFACE_DEF, LITERAL_CATCH,
                       LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR,
                       LITERAL_IF, LITERAL_SWITCH, LITERAL_SYNCHRONIZED,
                       LITERAL_TRY, LITERAL_WHILE, METHOD_DEF"/>
    </module>

    <!-- Rationale: while concision is generally preferred, this seems to be the
         prevailing Java style. It at least promotes consistency. -->
    <module name="NeedBraces">
      <property name="tokens" value="LITERAL_DO, LITERAL_ELSE, LITERAL_IF,
                                     LITERAL_FOR, LITERAL_WHILE"/>
    </module>

    <!-- Rationale: Keeping the closing brace on the same line as certain
         constructs is more concise; additionally, it is the prevailing Java
         style. -->
    <module name="RightCurly">
      <property name="option" value="same"/>
      <property name="tokens"
                value="LITERAL_TRY, LITERAL_CATCH, LITERAL_FINALLY, LITERAL_IF,
                       LITERAL_ELSE"/>
      <property name="shouldStartLine" value="true"/>
    </module>

    <!-- class design ====================================================== -->
    <!-- Rationale: final classes are difficult to test. Use package-private
         visibility and/or internal packages to control extension instead. -->
    <!-- <module name="DesignForExtension"/> -->

    <!-- Rationale: classes with only private constructors may as well be
         declared as final for documentation purposes (they cannot be
         subclassed anyway.) -->
    <module name="FinalClass"/>

    <!-- Rationale: there is no reason to instantiated classes with only static
         methods; making it impossible to do so serves as a form of
         documentation. -->
    <module name="HideUtilityClassConstructor"/>

    <module name="InnerTypeLast"/>

    <!-- Rationale: accessing constants through an interface is completely
         unnecessary. -->
    <module name="InterfaceIsType">
      <property name="allowMarkerInterfaces" value="true"/>
    </module>

    <module name="MutableException">
      <property name="format" value="^.*(Exception|Error)$"/>
    </module>

    <!-- Rationale: require client code to catch multiple exception types often
         forces duplicated error handling and is an onerous burden. Java 8 can
         allievate this, however. -->
    <module name="ThrowsCount">
      <property name="max" value="1"/>
    </module>

    <!-- Rationale: attempt to enforce encapsulation and immutability. -->
    <module name="VisibilityModifier">
      <property name="packageAllowed" value="false"/>
      <property name="protectedAllowed" value="false"/>
      <property name="publicMemberPattern" value="^serialVersionUID$"/>
    </module>

    <!-- coding =========================================================== -->
    <!-- Rationale: style preference; one less comma. -->
    <!-- <module name="ArrayTrailingComma"/> -->

    <!-- Rationale: inline conditionals increase concision, but use them
         judiciously. --> 
    <!-- <module name="AvoidInlineConditionals"/> -->

    <module name="CovariantEquals"/>

    <!-- Rationale: empty statements (;) are always unnecessary and less
         explicit than an empty block. Additionally, empty loops are generally
         unnecessary as well. -->
    <module name="EmptyStatement"/>

    <!-- Rationale: might as well avoid dereferencing null. -->
    <module name="EqualsAvoidNull"/>

    <!-- Rationale: defining only hashCode or equals but not both has
         ill-defined semantics. -->
    <module name="EqualsHashCode"/>

    <!-- Rationale: stateless code is easier to reason about. -->
    <module name="FinalLocalVariable">
      <property name="tokens" value="PARAMETER_DEF, VARIABLE_DEF"/>
    </module>

    <module name="HiddenField">
      <property name="tokens" value="PARAMETER_DEF, VARIABLE_DEF"/>

      <property name="ignoreFormat" value="^$"/>

      <!-- Rationale: constructor parameters should have the same name as
           their corresponding fields for documentation purposes. -->
      <property name="ignoreConstructorParameter" value="true"/>

      <!-- Rationale: mutator parameters should have the same name as their
           corresponding fields documentation purposes. -->
      <property name="ignoreSetter" value="true"/>

      <property name="ignoreAbstractMethods" value="false"/>
    </module>

    <module name="IllegalInstantiation">
      <property name="classes"
                value="java.lang.Boolean, java.lang.Character, java.lang.Byte,
                       java.lang.Double, java.lang.Float, java.lang.Integer,
                       java.lang.Long, java.lang.String,
                       java.util.StringBuffer"/>
    </module>

    <module name="IllegalToken">
      <property name="tokens" value="LITERAL_NATIVE"/>
    </module>

    <!-- Rational: Octal literals are not particularly useful. -->
    <module name="IllegalTokenText">
      <property name="tokens" value="NUM_INT, NUM_LONG"/>
      <property name="format" value="^0[^lx]"/>
      <property name="ignoreCase" value="true"/>
      <property name="message" value=""/>
    </module>

    <module name="InnerAssignment">
      <property name="tokens"
                value="ASSIGN, BAND_ASSIGN, BOR_ASSIGN, BSR_ASSIGN, BXOR_ASSIGN,
                       DIV_ASSIGN, MINUS_ASSIGN, MOD_ASSIGN, PLUS_ASSIGN,
                       SL_ASSIGN, SR_ASSIGN, STAR_ASSIGN"/>
    </module>

    <!-- Rationale: while magic numbers are bad, this rule can give very silly
         warnings. For example, "base = 16" does not need a static final
         field. -->
    <!-- <module name="MagicNumber"/> -->

    <module name="MissingSwitchDefault"/>

    <!-- Rationale: modifing a control variable in a loop certainly violates
         the principle of least astonishment. -->
    <module name="ModifiedControlVariable"/>

    <module name="RedundantThrows">
      <property name="allowUnchecked" value="false"/>
      <property name="allowSubclasses" value="false"/>
      <property name="logLoadErrors" value="true"/>
      <property name="suppressLoadErrors" value="false"/>
    </module>

    <module name="SimplifyBooleanExpression"/>
    <module name="SimplifyBooleanReturn"/>
    <module name="StringLiteralEquality"/>
    <module name="NestedForDepth"/>
    <module name="NestedIfDepth"/>
    <module name="NestedTryDepth"/>
    <module name="NoClone"/>
    <module name="NoFinalizer"/>
    <module name="SuperClone"/>

    <!-- Rationale: it's okay to catch Exception if your intention is to wrap
         it in a RuntimeException and propagate it. This can improve
         concision. -->
    <!-- <module name="IllegalCatch"/> -->

    <module name="IllegalThrows"/>
    <module name="PackageDeclaration"/>
    <module name="ReturnCount">
      <property name="severity" value="info"/>

      <!-- Rationale: methods should be too short to have a large number of
           returns anyway. -->
      <property name="max" value="3"/>

      <!-- Match all methods. -->
      <property name="format" value="^$"/>
    </module>
    <module name="IllegalType"/>
    <module name="DeclarationOrder"/>
    <module name="ParameterAssignment"/>
    <module name="ExplicitInitialization"/>
    <module name="DefaultComesLast"/>

    <!-- Rationale: default constructors improve concision, and are appropriate
         for package-private classes. -->
    <!-- <module name="MissingCtor"/> -->

    <module name="FallThrough"/>
    <module name="MultipleStringLiterals">
      <property name="severity" value="info"/>
    </module>
    <module name="MultipleVariableDeclarations"/>

    <!-- Rationale: line noise. -->
    <!-- <module name="RequireThis"/> -->
    <module name="UnnecessaryParentheses"/>

    <module name="OneStatementPerLine"/>
    <module name="AvoidStarImport"/>

    <!-- Rationale: static imports can improve concision in some cases. -->
    <!-- <module name="AvoidStaticImport"/> -->

    <module name="IllegalImport"/>
    <module name="RedundantImport"/>
    <module name="UnusedImports"/>
    <module name="ImportOrder">
      <property name="option" value="top"/>
      <property name="groups" value="java,javax"/>
    </module>
    <!-- unused <module name="ImportControl"/> -->

    <!-- Rationale: only API entries should have Javadoc comments. -->
    <!--
      <module name="JavadocType"/>
      <module name="JavadocMethod"/>
      <module name="JavadocVariable"/>
    -->

    <module name="JavadocStyle"/>

    <!-- Rationale: boolean expression complexity is unavoidable. Complex
         boolean expressions should be extracted from if statements and loop
         conditions into their own methods. -->
    <!-- <module name="BooleanExpressionComplexity"> -->

    <module name="ClassDataAbstractionCoupling">
      <property name="severity" value="info"/>
    </module>

    <module name="ClassFanOutComplexity">
      <property name="severity" value="info"/>
    </module>

    <module name="CyclomaticComplexity">
      <property name="severity" value="info"/>
      <property name="max" value="20"/>
    </module>

    <module name="NPathComplexity">
      <property name="severity" value="info"/>
    </module>

    <module name="JavaNCSS">
      <property name="severity" value="info"/>
    </module>

    <module name="TodoComment">
      <property name="severity" value="info"/>
    </module>

    <module name="UpperEll"/>
    <module name="ArrayTypeStyle"/>
    <module name="FinalParameters"/>

    <module name="Indentation">
      <property name="caseIndent" value="0"/>
    </module>

    <module name="TrailingComment"/>
    <module name="OuterTypeFilename"/>

    <!-- modifiers ========================================================= -->
    <module name="ModifierOrder"/>
    <module name="RedundantModifier"/>

    <!-- naming conventions ================================================ -->
    
    <!-- Rationale: AbstractClass is a fine name if Class (partially) implements
         an interface; otherwise, it is an inappropriate name. -->
    <!-- <module name="AbstractClassName"/> -->

    <module name="ClassTypeParameterName"/>
    <module name="ConstantName"/>
    <module name="LocalFinalVariableName"/>
    <module name="LocalVariableName"/>
    <module name="MemberName"/>
    <module name="MethodName"/>
    <module name="MethodTypeParameterName"/>
    <module name="PackageName">
      <property name="format" value="^[a-z]+(\.[a-z]+)*$"/>
    </module>
    <module name="ParameterName"/>
    <module name="StaticVariableName"/>
    <module name="TypeName"/>

    <!-- size violations =================================================== -->
    <module name="AnonInnerLength">
      <property name="severity" value="info"/>
      <property name="max" value="10"/>
    </module>

    <module name="ExecutableStatementCount">
      <property name="severity" value="info"/>

      <!-- Rationale: don't take this too seriously. -->
      <property name="max" value="5"/>
    </module>

    <module name="LineLength"/>
    <module name="MethodCount"/>
    <module name="MethodLength">
      <property name="max" value="50"/>
      <property name="severity" value="info"/>
    </module>
    <module name="OuterTypeNumber"/>
    <module name="ParameterNumber">
      <property name="severity" value="info"/>

      <!-- Rationale: I'd prefer 3, but it's simply impossible to avoid long
           parameter lists on factory methods or when implmenting a crummy
           interface. -->
      <property name="max" value="4"/>

      <!-- Rationale: constructors have as many parameters as needed to fill
           in their corresponding fields. -->
      <property name="tokens" value="METHOD_DEF"/>

    </module>

    <!-- whitespace ======================================================== -->
    <module name="EmptyForInitializerPad"/>
    <module name="EmptyForIteratorPad"/>
    <module name="GenericWhitespace"/>
    <module name="MethodParamPad"/>
    <module name="NoWhitespaceAfter">
      <property name="allowLineBreaks" value="false"/>
      <property name="tokens"
                value="BNOT, DEC, DOT, INC, LNOT, UNARY_MINUS, UNARY_PLUS"/>
    </module>
    <module name="NoWhitespaceBefore"/>
    <module name="OperatorWrap"/>
    <module name="ParenPad"/>
    <module name="TypecastParenPad"/>
    <module name="WhitespaceAfter"/>

    <module name="WhitespaceAround">
      <property name="tokens"
                value="ASSIGN, BAND, BAND_ASSIGN, BOR, BOR_ASSIGN, BSR,
                       BSR_ASSIGN, BXOR, BXOR_ASSIGN, COLON, DIV, DIV_ASSIGN,
                       EQUAL, GE, GT, LAND, LE, LITERAL_ASSERT, LITERAL_CATCH,
                       LITERAL_DO, LITERAL_ELSE, LITERAL_FINALLY, LITERAL_FOR,
                       LITERAL_IF, LITERAL_RETURN, LITERAL_SYNCHRONIZED,
                       LITERAL_TRY, LITERAL_WHILE, LOR, LT,MINUS, MINUS_ASSIGN,
                       MOD, MOD_ASSIGN, NOT_EQUAL, PLUS, PLUS_ASSIGN, QUESTION,
                       SL, SLIST, SL_ASSIGN, SR, SR_ASSIGN, STAR, STAR_ASSIGN,
                       TYPE_EXTENSION_AND"/>
    </module>

  </module>

  <module name="NewlineAtEndOfFile">
    <property name="lineSeparator" value="lf"/>
  </module>

  <module name="RegexpSingleline">
    <property name="format" value="  [/][/][A-z]"/>
    <property name="message" value="// comments must be followed by a space and be on their own line"/>
  </module>

  <module name="RegexpSingleline">
    <property name="format" value="\s+$"/>
    <property name="message" value="Line has trailing spaces."/>
  </module>

  <!-- Rationale: Checkstyle often gets this wrong. Additionally, internal
       packages have no need for Javadocs. -->
  <!-- <module name="JavadocPackage"/> -->

  <module name="FileLength">
    <property name="max" value="500"/>
  </module>
  <module name="FileTabCharacter"/>
  <!-- unused <module name="Translation"/> -->

</module>