# Code Style

Rules which enforce a specific coding style.
Table of Contents

## AnnotationsNamingConventions

Since: PMD 7.17.0

Priority: Medium (3)

Apex, while case-insensitive, benefits from a consistent code style to improve readability and maintainability. Enforcing PascalCase for annotations aligns with the established conventions and reduces ambiguity - promoting a unified coding standard.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.AnnotationsNamingConventionsRule

Example(s):

    // Incorrect:
    @istest
    private static void fooShouldBar() {
      //...
    }

    // Correct:
    @IsTest
    private static void fooShouldBar() {
      //...
    }

    //Incorrect:
    @testvisible
    private boolean doSomething = false;

    //Correct:
    @TestVisible
    private boolean doSomething = false;

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/AnnotationsNamingConventions" />

## ClassNamingConventions

Since: PMD 5.5.0

Priority: High (1)

Configurable naming conventions for type declarations. This rule reports type declarations which do not match the regex that applies to their specific kind (e.g. enum or interface). Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Pascal case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.ClassNamingConventionsRule

Example(s):

    public class FooClass { } // This is in pascal case, so it's ok

    public class fooClass { } // This will be reported unless you change the regex

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
testClassPattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to test class names
innerClassPattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to inner class names
innerInterfacePattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to inner interface names
abstractClassPattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to abstract class names
classPattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to class names
interfacePattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to interface names
enumPattern | [A-Z][a-zA-Z0-9_]* | Regex which applies to enum names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/ClassNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/ClassNamingConventions">
        <properties>
            <property name="testClassPattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="innerClassPattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="innerInterfacePattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="abstractClassPattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="classPattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="interfacePattern" value="[A-Z][a-zA-Z0-9_]*" />
            <property name="enumPattern" value="[A-Z][a-zA-Z0-9_]*" />
        </properties>
    </rule>

## FieldDeclarationsShouldBeAtStart

Since: PMD 6.23.0

Priority: Medium (3)

Field declarations should appear before method declarations within a class.

Note: Since PMD 7.21.0, properties are ignored. This means that fields can appear before or after properties (or fields and properties can be mixed) as long as all fields are placed before the first method declaration.

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.FieldDeclarationsShouldBeAtStartRule

Example(s):

    class Foo {
        public Integer someProperty { get; set; } // good
        public Integer someField; // good

        public void someMethod() {
        }

        public Integer anotherField; // bad
    }

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/FieldDeclarationsShouldBeAtStart" />

## FieldNamingConventions

Since: PMD 6.15.0

Priority: High (1)

Configurable naming conventions for field declarations. This rule reports variable declarations which do not match the regex that applies to their specific kind —e.g. constants (static final), static field, final field. Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Camel case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.FieldNamingConventionsRule

Example(s):

    public class Foo {
        Integer instanceField; // This is in camel case, so it's ok

        Integer INSTANCE_FIELD; // This will be reported unless you change the regex
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
enumConstantPattern | [A-Z][A-Z0-9_]* | Regex which applies to enum constant field names
constantPattern | [A-Z][A-Z0-9_]* | Regex which applies to constant field names
finalPattern | [a-z][a-zA-Z0-9]* | Regex which applies to final field names
staticPattern | [a-z][a-zA-Z0-9]* | Regex which applies to static field names
instancePattern | [a-z][a-zA-Z0-9]* | Regex which applies to instance field names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/FieldNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/FieldNamingConventions">
        <properties>
            <property name="enumConstantPattern" value="[A-Z][A-Z0-9_]*" />
            <property name="constantPattern" value="[A-Z][A-Z0-9_]*" />
            <property name="finalPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="staticPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="instancePattern" value="[a-z][a-zA-Z0-9]*" />
        </properties>
    </rule>

## ForLoopsMustUseBraces

Since: PMD 5.6.0

Priority: Medium (3)

Avoid using ‘for’ statements without using surrounding braces. If the code formatting or indentation is lost then it becomes difficult to separate the code being controlled from the rest.

This rule is defined by the following XPath expression:

    //ForLoopStatement/BlockStatement[@CurlyBrace= false()]
    |
    //ForEachStatement/BlockStatement[@CurlyBrace= false()]

Example(s):

    for (int i = 0; i < 42; i++) // not recommended
        foo();

    for (int i = 0; i < 42; i++) { // preferred approach
        foo();
    }

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/ForLoopsMustUseBraces" />

## FormalParameterNamingConventions

Since: PMD 6.15.0

Priority: High (1)

Configurable naming conventions for formal parameters of methods. This rule reports formal parameters which do not match the regex that applies to their specific kind (e.g. method parameter, or final method parameter). Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Camel case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.FormalParameterNamingConventionsRule

Example(s):

    public class Foo {
        public bar(Integer methodParameter) { } // This is in camel case, so it's ok

        public baz(Integer METHOD_PARAMETER) { } // This will be reported unless you change the regex
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
finalMethodParameterPattern | [a-z][a-zA-Z0-9]* | Regex which applies to final method parameter names
methodParameterPattern | [a-z][a-zA-Z0-9]* | Regex which applies to method parameter names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/FormalParameterNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/FormalParameterNamingConventions">
        <properties>
            <property name="finalMethodParameterPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="methodParameterPattern" value="[a-z][a-zA-Z0-9]*" />
        </properties>
    </rule>

## IfElseStmtsMustUseBraces

Since: PMD 5.6.0

Priority: Medium (3)

Avoid using if..else statements without using surrounding braces. If the code formatting or indentation is lost then it becomes difficult to separate the code being controlled from the rest.

This rule is defined by the following XPath expression:

    //IfBlockStatement/BlockStatement[@CurlyBrace= false()][count(child::*) > 0]
    |
    //IfElseBlockStatement/BlockStatement[@CurlyBrace= false()][count(child::*) > 0]

Example(s):

    // this is OK
    if (foo) x++;

    // but this is not
    if (foo)
        x = x+1;
    else
        x = x-1;

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/IfElseStmtsMustUseBraces" />

## IfStmtsMustUseBraces

Since: PMD 5.6.0

Priority: Medium (3)

Avoid using if statements without using braces to surround the code block. If the code formatting or indentation is lost then it becomes difficult to separate the code being controlled from the rest.

This rule is defined by the following XPath expression:

    //IfBlockStatement/BlockStatement[@CurlyBrace= false()]

Example(s):

    if (foo)    // not recommended
        x++;

    if (foo) {  // preferred approach
        x++;
    }

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/IfStmtsMustUseBraces" />

## LocalVariableNamingConventions

Since: PMD 6.15.0

Priority: High (1)

Configurable naming conventions for local variable declarations. This rule reports variable declarations which do not match the regex that applies to their specific kind (e.g. local variable, or final local variable). Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Camel case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.LocalVariableNamingConventionsRule

Example(s):

    public class Foo {
        public Foo() {
            Integer localVariable; // This is in camel case, so it's ok

            Integer LOCAL_VARIABLE; // This will be reported unless you change the regex
        }
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
finalLocalPattern | [a-z][a-zA-Z0-9]* | Regex which applies to final local variable names
localPattern | [a-z][a-zA-Z0-9]* | Regex which applies to local variable names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/LocalVariableNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/LocalVariableNamingConventions">
        <properties>
            <property name="finalLocalPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="localPattern" value="[a-z][a-zA-Z0-9]*" />
        </properties>
    </rule>

## MethodNamingConventions

Since: PMD 5.5.0

Priority: High (1)

Configurable naming conventions for method declarations. This rule reports method declarations which do not match the regex that applies to their specific kind (e.g. static method, or test method). Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Camel case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.MethodNamingConventionsRule

Example(s):

    public class Foo {
        public void instanceMethod() { } // This is in camel case, so it's ok

        public void INSTANCE_METHOD() { } // This will be reported unless you change the regex

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
testPattern | [a-z][a-zA-Z0-9]* | Regex which applies to test method names
staticPattern | [a-z][a-zA-Z0-9]* | Regex which applies to static method names
instancePattern | [a-z][a-zA-Z0-9]* | Regex which applies to instance method names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/MethodNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/MethodNamingConventions">
        <properties>
            <property name="testPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="staticPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="instancePattern" value="[a-z][a-zA-Z0-9]*" />
        </properties>
    </rule>

## OneDeclarationPerLine

Since: PMD 6.7.0

Priority: High (1)

Apex allows the use of several variables declaration of the same type on one line. However, it can lead to quite messy code. This rule looks for several declarations on the same line.

This rule is defined by the following XPath expression:

    //VariableDeclarationStatements
      [count(VariableDeclaration) > 1 and ($reportInForLoopInitializer = true() or name(parent::*) != 'ForLoopStatement')]
      [$strictMode or count(distinct-values(VariableDeclaration/@BeginLine)) != count(VariableDeclaration)]
    |
    //FieldDeclarationStatements
      [count(FieldDeclaration) > 1]
      [$strictMode or count(distinct-values(FieldDeclaration/VariableExpression/@BeginLine)) != count(FieldDeclaration/VariableExpression)]

Example(s):

    Integer a, b;   // not recommended

    Integer a,
            b;      // ok by default, can be flagged setting the strictMode property

    Integer a;      // preferred approach
    Integer b;

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
strictMode | false | If true, mark combined declaration even if the declarations are on separate lines.
reportInForLoopInitializer | true | If false, multiple declarations in a for loop initializer are not flagged.

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/OneDeclarationPerLine" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/OneDeclarationPerLine">
        <properties>
            <property name="strictMode" value="false" />
            <property name="reportInForLoopInitializer" value="true" />
        </properties>
    </rule>

## PropertyNamingConventions

Since: PMD 6.15.0

Priority: High (1)

Configurable naming conventions for property declarations. This rule reports property declarations which do not match the regex that applies to their specific kind (e.g. static property, or instance property). Each regex can be configured through properties.

By default this rule uses the standard Apex naming convention (Camel case).

This rule is defined by the following Java class: net.sourceforge.pmd.lang.apex.rule.codestyle.PropertyNamingConventionsRule

Example(s):

    public class Foo {
        public Integer instanceProperty { get; set; } // This is in camel case, so it's ok

        public Integer INSTANCE_PROPERTY { get; set; } // This will be reported unless you change the regex
    }

This rule has the following properties:

Name | Default Value | Description
--- | --- | ---
staticPattern | [a-z][a-zA-Z0-9]* | Regex which applies to static property names
instancePattern | [a-z][a-zA-Z0-9]* | Regex which applies to instance property names

Use this rule with the default properties by just referencing it:

    <rule ref="category/apex/codestyle.xml/PropertyNamingConventions" />

Use this rule and customize it:

    <rule ref="category/apex/codestyle.xml/PropertyNamingConventions">
        <properties>
            <property name="staticPattern" value="[a-z][a-zA-Z0-9]*" />
            <property name="instancePattern" value="[a-z][a-zA-Z0-9]*" />
        </properties>
    </rule>

## WhileLoopsMustUseBraces

Since: PMD 5.6.0

Priority: Medium (3)

Avoid using ‘while’ statements without using braces to surround the code block. If the code formatting or indentation is lost then it becomes difficult to separate the code being controlled from the rest.

This rule is defined by the following XPath expression:

    //WhileLoopStatement/BlockStatement[@CurlyBrace= false()]

Example(s):

    while (true)    // not recommended
        x++;

    while (true) {  // preferred approach
        x++;
    }

Use this rule by referencing it:

    <rule ref="category/apex/codestyle.xml/WhileLoopsMustUseBraces" />