checkstyle/config/pmd.xml

<?xml version="1.0"?>
<ruleset name="PMD ruleset for Checkstyle"
        xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
         http://pmd.sourceforge.net/ruleset_2_0_0.xsd">
  <description>
    PMD ruleset for Checkstyle
  </description>
  <rule ref="rulesets/java/basic.xml"/>
  <rule ref="rulesets/java/braces.xml"/>
  <rule ref="rulesets/java/clone.xml"/>
  <rule ref="rulesets/java/codesize.xml">
    <!-- we are using CyclomaticComplexity -->
    <exclude name="ModifiedCyclomaticComplexity"/>
    <!-- we are using CyclomaticComplexity -->
    <exclude name="StdCyclomaticComplexity"/>
  </rule>

  <rule ref="rulesets/java/codesize.xml/CyclomaticComplexity">
    <properties>
      <property name="showClassesComplexity" value="false"/>
      <property name="reportLevel" value="11"/>
      <!-- DeclarationOrder - 'visitToken' has just big SWITCH block which contains IF blocks.
           If we split the block to several methods it will demage readibility.
           validateCli is not reasonable to split as encapsulation of logic will be damaged
           getDetails - huge Switch, it has to be monolithic
           JavadocMethodCheck, JavadocStyleCheck, JavadocUtils.getJavadocTags() - deprecated
           FinalLocalVariableCheck.visitToken() - it is just big switch , not could be done
           GenericWhitespaceCheck.processSingleGeneric() - it contains a lot of similar to each other and very simple condition
           VariableDeclarationUsageDistanceCheck, CustomImportOrderCheck - it is not OK to have such a complicated logic need to be refactored.
      -->
      <property name="violationSuppressXPath" value="//DeclarationOrder[@Name='visitToken'] and //MethodDeclaration[@Name='validateCli' and ../../..[@Image='Main']] | //MethodDeclaration[@Name='processSingleGeneric' and ../../..[@Image='GenericWhitespaceCheck']] | //MethodDeclaration[@Name='visitToken' and ../../..[@Image='FinalLocalVariableCheck']] | //MethodDeclaration[@Name='getJavadocTags' and ../../..[@Image='JavadocUtils']] | //MethodDeclaration[@Name='getDetails' and ../../..[@Image='RightCurlyCheck']] | //ClassOrInterfaceDeclaration[@Image='JavadocMethodCheck' or @Image='JavadocStyleCheck' or @Image='VariableDeclarationUsageDistanceCheck' or @Image='CustomImportOrderCheck']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/codesize.xml/NPathComplexity">
    <properties>
      <!-- JavadocMethodCheck - deprecated
           WhitespaceAroundCheck.isNotRelevantSituation - npath = 216, but additional extraction
                                of expression to separate method does not make sense as it will
                                damage encapsulation of that check.
      -->
      <property name="violationSuppressXPath" value="//MethodDeclaration[@Name='isNotRelevantSituation' and ../../..[@Image='WhitespaceAroundCheck']] | //MethodDeclaration[@Name='validateCli' and ../../..[@Image='Main']] | //ClassOrInterfaceDeclaration[@Image='JavadocMethodCheck' or @Image='JavadocStyleCheck']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/codesize.xml/TooManyMethods">
    <properties>
      <property name="maxmethods" value="20"/>
      <!-- Reducing the number of methods requires making excess hierarchy or duplicating code, or making existing methods too complex. -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='RequireThisCheck']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/codesize.xml/ExcessiveClassLength">
    <properties>
      <!-- *TokenTypes are special classes that a big due to a lot of description comments -->
      <!-- JavadocMethodCheck is deprecated class, till it is redone to use JavadocAst -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='JavadocTokenTypes' or @Image='TokenTypes' or @Image='JavadocMethodCheck' or @Image='RequireThisCheck']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/codesize.xml/ExcessiveMethodLength">
    <properties>
      <!-- JavadocMethodCheck is deprecated class, till it is redone to use JavadocAst -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='JavadocMethodCheck']"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/comments.xml">
    <!-- <exclude name="CommentRequired"/> -->
    <!-- we use class comments as source for xdoc files, so content is big and that is by design -->
    <exclude name="CommentSize"/>
  </rule>
  <rule ref="rulesets/java/comments.xml/CommentRequired">
    <properties>
      <!-- *TokenTypes are special class, comments are as trailing comments -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='JavadocTokenTypes'] | //Annotation/MarkerAnnotation//Name[@Image='Override']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/comments.xml/CommentSize">
    <properties>
      <!-- we use class comments as source for xdoc files, so content is big and that is by design -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration | //PackageDeclaration | //ClassOrInterfaceDeclaration[@Image='JavadocTagInfo'] | //ClassOrInterfaceDeclaration[@Image='SeverityLevel'] | //ClassOrInterfaceDeclaration[@Image='LeftCurlyOption'] | //ClassOrInterfaceDeclaration[@Image='RightCurlyOption'] | //ClassOrInterfaceDeclaration[@Image='ImportOrderOption']"/>
      <property name="maxLines" value="8"/>
      <property name="maxLineLength" value="100"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/controversial.xml">
    <!-- calling super() is completely pointless, no matter if class inherits anything or not; it is meaningful only if you do not call implicit constructor of base class -->
    <exclude name="CallSuperInConstructor"/>
    <!-- We reuse Check instances between java files, we need to clear state of class in beginTree() methods -->
    <exclude name="NullAssignment"/>
    <!-- it is possible only in functional languages and fanatically-pristine code, without additional option that are done at ReturnCountExtendedCheck it is not good rule -->
    <exclude name="OnlyOneReturn"/>
    <!-- opposite to UnnecessaryConstructor -->
    <exclude name="AtLeastOneConstructor"/>
    <!-- deprecated by PMD -->
    <exclude name="BooleanInversion"/>
    <!-- that rule is too buggy, too much false positives-->
    <exclude name="DataflowAnomalyAnalysis"/>
    <!-- turning local variables to fields create design problems and extend scope of variable -->
    <exclude name="AvoidFinalLocalVariable"/>
    <!-- conflicts with names that does not mean in/out -->
    <exclude name="AvoidPrefixingMethodParameters"/>
    <!-- that is not practical, no options to allow some magic numbers, we will use our implementation -->
    <exclude name="AvoidLiteralsInIfCondition"/>
    <!-- Checkstyle is not thread safe -->
    <exclude name="UseConcurrentHashMap"/>
  </rule>
  <rule ref="rulesets/java/controversial.xml/AvoidUsingShortType">
    <properties>
      <!-- that class integrates checkstyle and antlr that is why it has a lot of imports -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='AutomaticBean']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/coupling.xml">
    <!-- produce too much violations, suppressed till we figure out how useful that metrics-->
    <exclude name="LawOfDemeter"/>
    <!-- this rule is for managing import, we have special Check for that -->
    <exclude name="LoosePackageCoupling"/>
  </rule>
  <rule ref="rulesets/java/coupling.xml/ExcessiveImports">
    <properties>
      <!-- TreeWalker integrates Checkstyle and antlr and CheckstyleAntTask integrates Checkstyle
       with Ant. Checker collects external resource locations and setup configuration. -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='TreeWalker' or @Image='CheckstyleAntTask' or @Image='Checker']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/coupling.xml/CouplingBetweenObjects">
    <properties>
      <!-- I do not see any problem , looks like false positive -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='HandlerFactory']"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/design.xml">
    <!-- extra final modifier does not make code more secure in that cases-->
    <exclude name="ImmutableField"/>
    <!-- this rule does not have any option, unreasonable to use -->
    <exclude name="MissingBreakInSwitch"/>
    <!-- we need compare by ref as Tree structure is immutable, we can easily rely on refs -->
    <exclude name="CompareObjectsWithEquals"/>
    <!-- we will use our own declaration order logic -->
    <exclude name="FieldDeclarationsShouldBeAtStartOfClass"/>
    <!-- too much alarms of Checks, we will never move logic out of Check, each Check is independent logic container -->
    <exclude name="GodClass"/>
  </rule>

  <rule ref="rulesets/java/design.xml/ConfusingTernary">
    <properties>
     <!-- false positives on IF_ELSE-IF-ELSE-IF -->
    <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='XMLLogger']//MethodDeclarator[@Image='isReference'] | //ClassOrInterfaceDeclaration[@Image='DetailAST']//MethodDeclarator[@Image='addPreviousSibling'] | //ClassOrInterfaceDeclaration[@Image='AnnotationLocationCheck']//MethodDeclarator[@Image='checkAnnotations'] | //ClassOrInterfaceDeclaration[@Image='PkgControl']//MethodDeclarator[@Image='checkAccess'] | //ClassOrInterfaceDeclaration[@Image='HandlerFactory']//MethodDeclarator[@Image='getHandler']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/design.xml/AccessorClassGeneration">
    <properties>
      <!-- We do instantiation by way of private constructors from outside of the constructor’s
      class in DetectorOptions intentionally as it is a whole idea of Builder pattern. -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='DetectorOptions']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/design.xml/PreserveStackTrace">
    <properties>
     <!-- yes we swallow one exception and try to do another attempt, second attempt does not hide cause -->
    <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='PackageObjectFactory']//MethodDeclarator[@Image='createModule']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/design.xml/EmptyMethodInAbstractClassShouldBeAbstract">
    <properties>
     <!-- Can not change API -->
    <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='AbstractFileSetCheck'
    or @Image='AbstractCheck' or @Image='AbstractJavadocCheck']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/design.xml/AbstractClassWithoutAnyMethod">
    <properties>
     <!-- Can not change API -->
    <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='Check']"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/design.xml/AvoidDeeplyNestedIfStmts">
    <properties>
      <!-- default is 3 but we try to use single point of exit from method and that require extra IFs -->
      <property name="problemDepth" value="4"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/empty.xml"/>
  <rule ref="rulesets/java/finalizers.xml"/>
  <rule ref="rulesets/java/imports.xml"/>
  <rule ref="rulesets/java/javabeans.xml">
    <!-- too many false-positives -->
    <exclude name="BeanMembersShouldSerialize"/>
  </rule>
  <rule ref="rulesets/java/junit.xml"/>
  <rule ref="rulesets/java/logging-jakarta-commons.xml"/>

  <rule ref="rulesets/java/logging-java.xml"/>
  <rule ref="rulesets/java/logging-java.xml/SystemPrintln">
    <properties>
      <!-- it is ok to use println in CLI class -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='Main']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/logging-java.xml/AvoidPrintStackTrace">
    <properties>
      <!-- it is ok to use print stack trace in CLI class -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='Main']"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/migrating.xml"/>

  <rule ref="rulesets/java/naming.xml">
    <!-- we use CheckstyleCustomShortVariable, to control lenght (will be fixed in PMD 5.4) and skip Override methods -->
    <exclude name="ShortVariable"/>
  </rule>
<rule name="CheckstyleCustomShortVariable"
      message="Avoid variables with short names that shorter than 2 symbols: {0}"
      language="java"
      class="net.sourceforge.pmd.lang.rule.XPathRule"
      externalInfoUrl="">
<description>
   Fields, local variables, or parameter names that are very short are not helpful to the reader.
</description>
<priority>3</priority>
<properties>
   <property name="xpath">
       <value>
           <![CDATA[
 //VariableDeclaratorId[string-length(@Image) < 2]
 [not(ancestor::ForInit)]
 [not(../../VariableDeclarator and ../../../LocalVariableDeclaration and ../../../../ForStatement)]
 [not((ancestor::FormalParameter) and (ancestor::TryStatement))]
 [not(ancestor::ClassOrInterfaceDeclaration[//MarkerAnnotation/Name[pmd-java:typeof(@Image, 'java.lang.Override', 'Override')]])]
            ]]>
       </value>
   </property>
</properties>
</rule>
  <rule ref="rulesets/java/naming.xml/AbstractNaming">
    <properties>
     <!-- We can not brake compatibility with previous versions -->
     <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='Check']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/naming.xml/LongVariable">
    <properties>
      <!-- nothing bad in long and descriptive variable names if only they fit line, but still keep it reasonable -->
      <property name="minimum" value="45"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/naming.xml/ShortClassName">
    <properties>
      <!-- Main is good name for class containing main method, Tag as inner class name is also fine -->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='Main' or @Image='Tag']"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/optimizations.xml">
    <!--produces more false-positives than real problems-->
    <exclude name="AvoidInstantiatingObjectsInLoops"/>
    <!--pollutes code with modifiers-->
    <exclude name="LocalVariableCouldBeFinal"/>
    <!--pollutes code with modifiers-->
    <exclude name="MethodArgumentCouldBeFinal"/>
    <!--not configurable, decreases readability-->
    <exclude name="UseStringBufferForStringAppends"/>
  </rule>
  <rule ref="rulesets/java/strictexception.xml/AvoidCatchingGenericException">
    <properties>
      <!-- There is no other way to deliver filename that was under processing.
           See https://github.com/checkstyle/checkstyle/issues/2285-->
      <property name="violationSuppressXPath" value="//MethodDeclaration[@Name='processFiles' and ../../..[@Image='Checker']]"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/strictexception.xml/AvoidThrowingRawExceptionTypes">
    <properties>
      <!-- There is no other way to deliver filename that was under processing.
           See https://github.com/checkstyle/checkstyle/issues/2285-->
      <property name="violationSuppressXPath" value="//MethodDeclaration[@Name='processFiles' and ../../..[@Image='Checker']]"/>
    </properties>
  </rule>

  <rule ref="rulesets/java/strings.xml"/>
  <rule ref="rulesets/java/sunsecure.xml/MethodReturnsInternalArray">
    <properties>
      <!--It's not important when array is empty-->
      <property name="violationSuppressXPath" value="//ClassOrInterfaceDeclaration[@Image='JavadocNodeImpl']"/>
    </properties>
  </rule>
  <rule ref="rulesets/java/typeresolution.xml"/>
  <rule ref="rulesets/java/unnecessary.xml"/>
  <rule ref="rulesets/java/unusedcode.xml"/>

</ruleset>