Fork me on GitHub

PMD Rulesets index: Current Rulesets

List of rulesets and rules contained in each ruleset.

  • ApexUnit: These rules deal with different problems that can occur with Apex unit tests.
  • Complexity: The Complexity ruleset contains rules that find problems related to code size or complexity.
  • Performance: The Performance ruleset contains a collection of good practices which should be followed.
  • Style: The Style Ruleset contains rules regarding preferred usage of names and identifiers.

ApexUnit (apex)

  • ApexUnitTestClassShouldHaveAsserts: Apex unit tests should include at least one assertion. This makes the tests more robust, and using assert with messages provide the developer a clearer idea of what the test does.

Complexity (apex)

  • AvoidDeeplyNestedIfStmts: Avoid creating deeply nested if-then statements since they are harder to read and error-prone to maintain.
  • ExcessiveParameterList: Methods with numerous parameters are a challenge to maintain, especially if most of them share thesame datatype. These situations usually denote the need for new objects to wrap the numerous parameters.
  • ExcessiveClassLength: Excessive class file lengths are usually indications that the class may be burdened with excessive responsibilities that could be provided by external classes or functions. In breaking these methodsapart the code becomes more managable and ripe for reuse.
  • NcssMethodCount: This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
  • NcssTypeCount: This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given type. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
  • NcssConstructorCount: This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of linesof code for a given constructor. NCSS ignores comments, and counts actual statements. Using this algorithm,lines of code that are split are counted as one.
  • StdCyclomaticComplexity: Complexity directly affects maintenance costs is determined by the number of decision points in a method plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls. Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denotehigh complexity, and 11+ is very high complexity.
  • TooManyFields: Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields,possibly through grouping related fields in new objects. For example, a class with individual city/state/zip fields could park them within a single Address field.
  • ExcessivePublicCount: Classes with large numbers of public methods and attributes require disproportionate testing effortssince combinational side effects grow rapidly and increase risk. Refactoring these classes intosmaller ones not only increases testability and reliability but also allows new variations to bedeveloped easily.

Performance (apex)

  • AvoidSoqlInLoops: New objects created within loops should be checked to see if they can created outside them and reused.
  • AvoidDmlStatementsInLoops: Avoid DML statements inside loops to avoid hitting the DML governor limit. Instead, try to batch up the data into a list and invoke your DML once on that list of data outside the loop.

Default ruleset used by the CodeClimate Engine for Salesforce.com Apex (apex)

Style (apex)

  • VariableNamingConventions: A variable naming conventions rule - customize this to your liking. Currently, itchecks for final variables that should be fully capitalized and non-final variablesthat should not include underscores.
  • MethodNamingConventions: Method names should always begin with a lower case character, and should not contain underscores.
  • AvoidGlobalModifier: Global classes should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.Many interfaces (e.g. Batch) required global modifiers in the past but don’t require this anymore. Don’t look yourself in.