| rule | Description | url | kpi | example |
|---|---|---|---|---|
| ApexAssertionsShouldIncludeMessage | Apex test assert statement should make use of the message parameter. | https://pmd.github.io/latest/pmd_rules_apex_bestpractices.html#apexassertionsshouldincludemessage | Maintainability | |
| ClassNamingConventions | Configurable naming conventions for type declarations. This rule reports_x000D_ type declarations which do not match the regex that applies to their_x000D_ specific kind (e.g. enum or interface). Each regex can be configured through_x000D_ properties._x000D_ _x000D_ By default this rule uses the standard Apex naming convention (Pascal case). | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#classnamingconventions | Maintainability | _x000D_ public class FooClass { } // This is in pascal case, so it's ok_x000D_ public class fooClass { } // This will be reported unless you change the regex_x000D_ |
| IfElseStmtsMustUseBraces | Avoid using if..else statements without using surrounding braces. If the code formatting_x000D_ or indentation is lost then it becomes difficult to separate the code being controlled_x000D_ from the rest. | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#ifelsestmtsmustusebraces | Maintainability | _x000D_ // this is OK_x000D_ if (foo) x++;_x000D_ // but this is not_x000D_ if (foo)_x000D_ x = x+1;_x000D_ else_x000D_ x = x-1;_x000D_ |
| IfStmtsMustUseBraces | Avoid using if statements without using braces to surround the code block. If the code_x000D_ formatting or indentation is lost then it becomes difficult to separate the code being_x000D_ controlled from the rest. | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#ifstmtsmustusebraces | Maintainability | _x000D_ if (foo) // not recommended_x000D_ x++;_x000D_ if (foo) { // preferred approach_x000D_ x++;_x000D_ }_x000D_ |
| FieldNamingConventions | Configurable naming conventions for field declarations. This rule reports variable declarations_x000D_ which do not match the regex that applies to their specific kind ---e.g. constants (static final),_x000D_ static field, final field. Each regex can be configured through properties._x000D_ _x000D_ By default this rule uses the standard Apex naming convention (Camel case). | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#fieldnamingconventions | Maintainability | _x000D_ public class Foo {_x000D_ Integer instanceField; // This is in camel case, so it's ok_x000D_ Integer INSTANCE_FIELD; // This will be reported unless you change the regex_x000D_ }_x000D_ |
| ForLoopsMustUseBraces | Avoid using 'for' statements without using surrounding braces. If the code formatting or_x000D_ indentation is lost then it becomes difficult to separate the code being controlled_x000D_ from the rest. | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#forloopsmustusebraces | Maintainability | _x000D_ for (int i = 0; i < 42; i++) // not recommended_x000D_ foo();_x000D_ for (int i = 0; i < 42; i++) { // preferred approach_x000D_ foo();_x000D_ }_x000D_ |
| FormalParameterNamingConventions | Configurable naming conventions for formal parameters of methods._x000D_ This rule reports formal parameters which do not match the regex that applies to their_x000D_ specific kind (e.g. method parameter, or final method parameter). Each regex can be_x000D_ configured through properties._x000D_ _x000D_ By default this rule uses the standard Apex naming convention (Camel case). | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#formalparameternamingconventions | Maintainability | _x000D_ public class Foo {_x000D_ public bar(Integer methodParameter) { } // This is in camel case, so it's ok_x000D_ public baz(Integer METHOD_PARAMETER) { } // This will be reported unless you change the regex_x000D_ }_x000D_ |
| MethodNamingConventions | Configurable naming conventions for method declarations. This rule reports_x000D_ method declarations which do not match the regex that applies to their_x000D_ specific kind (e.g. static method, or test method). Each regex can be_x000D_ configured through properties._x000D_ _x000D_ By default this rule uses the standard Apex naming convention (Camel case). | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#methodnamingconventions | Maintainability | _x000D_ public class Foo {_x000D_ public void instanceMethod() { } // This is in camel case, so it's ok_x000D_ public void INSTANCE_METHOD() { } // This will be reported unless you change the regex_x000D_ |
| OneDeclarationPerLine | Apex allows the use of several variables declaration of the same type on one line. However, it_x000D_ can lead to quite messy code. This rule looks for several declarations on the same line. | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#onedeclarationperline | Maintainability | _x000D_ Integer a, b; // not recommended_x000D_ Integer a,_x000D_ b; // ok by default, can be flagged setting the strictMode property_x000D_ Integer a; // preferred approach_x000D_ Integer b;_x000D_ |
| PropertyNamingConventions | Configurable naming conventions for property declarations. This rule reports_x000D_ property declarations which do not match the regex that applies to their_x000D_ specific kind (e.g. static property, or instance property). Each regex can be_x000D_ configured through properties._x000D_ _x000D_ By default this rule uses the standard Apex naming convention (Camel case). | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#propertynamingconventions | Maintainability | _x000D_ public class Foo {_x000D_ public Integer instanceProperty { get; set; } // This is in camel case, so it's ok_x000D_ public Integer INSTANCE_PROPERTY { get; set; } // This will be reported unless you change the regex_x000D_ }_x000D_ |
| WhileLoopsMustUseBraces | Avoid using 'while' statements without using braces to surround the code block. If the code_x000D_ formatting or indentation is lost then it becomes difficult to separate the code being_x000D_ controlled from the rest. | https://pmd.github.io/latest/pmd_rules_apex_codestyle.html#whileloopsmustusebraces | Maintainability | _x000D_ while (true) // not recommended_x000D_ x++;_x000D_ while (true) { // preferred approach_x000D_ x++;_x000D_ }_x000D_ |
| ApexDoc | This rule validates that:_x000D_ _x000D_ * ApexDoc comments are present for classes, methods, and properties that are public or global, excluding_x000D_ overrides and test classes (as well as the contents of test classes)._x000D_ * ApexDoc comments are present for classes, methods, and properties that are protected or private, depending_x000D_ on the properties `reportPrivate` and `reportProtected`._x000D_ * ApexDoc comments should contain @description._x000D_ * ApexDoc comments on non-void, non-constructor methods should contain @return._x000D_ * ApexDoc comments on void or constructor methods should not contain @return._x000D_ * ApexDoc comments on methods with parameters should contain @param for each parameter, in the same_x000D_ order as the method signature._x000D_ _x000D_ Method overrides and tests are both exempted from having ApexDoc. | https://pmd.github.io/latest/pmd_rules_apex_documentation.html#apexdoc | Maintainability | /** * @description Hello World */ public class HelloWorld { /** * @description Bar * @return Bar */ public Object bar() { return null; } } |