Apex general best practices


This article is based on the PMD documentation article. See the original article on the PMD site: PMD: best practices.

Below are the generally accepted best practices. 

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.

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.bestpractices.ApexUnitTestClassShouldHaveAssertsRule

Example

@isTest
public class Foo {
   public static testMethod void testSomething() {
      Account a = null;
   // This is better than having a NullPointerException
   // System.assertNotEquals(a, null, 'account not found');
   a.toString();
   }
}

Properties

NameDefault ValueDescription
cc_categories[Style]Code Climate Categories
cc_remediation_points_multiplier1Code Climate Remediation Points multiplier
cc_block_highlightingfalseCode Climate Block Highlighting

ApexUnitTestShouldNotUseSeeAllDataTrue

Apex unit tests should not use @isTest(seeAllData=true) because it opens up the existing database data for unexpected modification by tests.

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.bestpractices.ApexUnitTestShouldNotUseSeeAllDataTrueRule

Example

@isTest(seeAllData = true)
public class Foo { 
	public static testMethod void testSomething() { 
		Account a = null; 
	// This is better than having a NullPointerException 
	// System.assertNotEquals(a, null, 'account not found'); 
	a.toString(); 
	} 
}

Properties

NameDefault ValueDescription
cc_categories[Style]Code Climate Categories
cc_remediation_points_multiplier1Code Climate Remediation Points multiplier
cc_block_highlightingfalseCode Climate Block Highlighting

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 lock yourself in.

This rule is defined by the following Java class: 

net.sourceforge.pmd.lang.apex.rule.bestpractices.AvoidGlobalModifierRule

Example

global class Unchangeable {
    global UndeletableType unchangable(UndeletableType param) {
        // ...
    }
}

Properties

NameDefault ValueDescription
cc_categories[Style]Code Climate Categories
cc_remediation_points_multiplier1Code Climate Remediation Points multiplier
cc_block_highlightingfalseCode Climate Block Highlighting

AvoidLogicInTrigger

As triggers do not allow methods like regular classes they are less flexible and suited to apply good encapsulation style. Therefore delegate the triggers work to a regular class (often called Trigger handler class).

This rule is defined by the following Java class:

net.sourceforge.pmd.lang.apex.rule.bestpractices.AvoidLogicInTriggerRule

Example

trigger Accounts on Account (before insert, before update, before delete, after insert, after update, after delete, after undelete) {
    for(Account acc : Trigger.new) {
        if(Trigger.isInsert) {
            // ...
        }

        // ...

        if(Trigger.isDelete) {
            // ...
        }
    }
}

Properties

NameDefault ValueDescription
cc_categories[Style]Code Climate Categories
cc_remediation_points_multiplier1Code Climate Remediation Points multiplier
cc_block_highlightingfalseCode Climate Block Highlighting

What's here


Related content

Related content

 PMD: best practices




Last modified on Jul 14, 2020