Advanced Apex Training: Apex Best Practices


This article dives into what we, developers at Solunus, recently learned as we attended ‘Apex Best Practices’ training session at our Global Delivery Center, Hyderabad. This is one of many advanced topics the company organized for all Salesforce developers as part of the continuous improvement and learning. I took some time to write this blog to reflect on all the things I learned (with some of code samples) from our Senior Architect and I hope this will help other developers too. For more details, please watch this awesome video ‘Winter ’16 Release – Overview & Highlights‘.


Follow along, as I show you all the guidelines you should consider when writing code for your next Salesforce applications.


Governor Limits

Why governor limits?

Force.com is built on a multi-tenant Architecture. In order to ensure that Apex code of a single tenant does not consume significant amount of shared resources on Force.com platform and to ensure every tenant gets equal share of the platform resources.

Per-transaction Apex Limits

Total # of SOQL Queries: 100 (Sync) | 200 (Async) Total # of records retrieved: 50K Total # of DML statements: 150 Total # of records processed by DML: 10K Total heap size: 6MB (Sync) | 12MB (Async) Maximum SOQL query runtime before Salesforce cancels the transaction: 120 seconds


SOQL

Avoid writing non-selective queries except during batch processing. Avoid using only negative operators (!=)

Use Primary Keys, Foreign Keys, CreatedDate, LastModifiedDate, External ID or Unique Fields in query filters.


Example for Batch Processing : Mass Delete of Records


Bad Query (When record count exceeds 100K)

SELECT ID, NAME FROM ACCOUNT

SELECT ID, NAME FROM ACCOUNT WHERE NAME != ‘ ‘


Good Queries

SELECT ID, NAME FROM ACCOUNT LIMIT 5

SELECT ID, NAME FROM ACCOUNT WHERE ID IN :IDS (Only when ID list is small)

SELECT ID, NAME FROM ACCOUNT WHERE NAME != ‘’ AND OWNERID IN :OID


What happens if I dont write selective queries?

Salesforce could throw a runtime error like this:

System.QueryException: Non-selective query against large object type (more than 100k rows). Consider an indexed filter or contact salesforce.com about custom indexing


Best Practices for Apex Classes

  • Apex code must provide proper exception handling.

  • When querying large data sets, use a SOQL “for” loop.

  • We should not use SOQL or SOSL queries inside loops.

  • Apex code must provide proper exception handling.

  • We should prevent SOQL and SOSL injection attacks by using static queries, binding variables or escape single quotes method.

  • Should use SOSL rather than SOQL where possible.

  • Should not use DML statements inside loops.

  • Should not use Async(@future) methods inside loops.

  • Should use Asynchronous Apex(@future annotation) for logic that does not be executed synchronous.

  • Asynchronous Apex should be Bulkified.

  • We should not use hardcoded IDs as they may cause problem when moved to production.


Graceful Design of the Code


BAD CODE:

public class CustomCalendarUtil {

public static String getMonth(Integer month){ String varMonth = ‘’; if(month==1){ varMonth = ‘January’; } else if(month==2){ varMonth = ‘February’; } .. .. return varMonth; } }

This is functionally correct code but is a maintenance overhead due To many if else statements.


GOOD CODE:

public class CustomCalendarUtil {

static Map<Integer, String> monthMap = new Map<Integer, String>();

private static void init(){ monthMap.put(1, ‘January’); monthMap.put(2, ‘February’); monthMap.put(3, ‘March’); }

public String getMonth(Integer month){ return monthMap.get(month); } }


Use static methods, avoid storing state


BAD CODE

public class CustomCalendarUtil {

Map<Integer, String> monthMap = new Map<Integer, String>();

private void init(){ monthMap.put(1, ‘January’); monthMap.put(2, ‘February’); monthMap.put(3, ‘March’); }

public String getMonth(Integer month){ init(); return monthMap.get(month); } }


GOOD CODE public class CustomCalendarUtil {

static Map<Integer, String> monthMap = new Map<Integer, String>();

static { monthMap.put(1, ‘January’); monthMap.put(2, ‘February’); monthMap.put(3, ‘March’);

}

public static String getMonth(Integer month){ return monthMap.get(month); } }


Best Practices for Triggers:

  • Execute DML statements using collections instead of individual records per DML statement.

  • Should use collections in SOQL “WHERE” clauses to retrieve all records back in single query.

  • Use a consistent naming convention including Object name(ex: contactTrigger)

  • Best to have one Trigger to each object.

  • Complex logics should be avoided to simplify testing and reuse.

  • Bulkify “helper” classes or methods.

  • Trigger should be bulkified and be able to process up to 200 records for each call.


Avoid SOQL inside for loop


BAD CODE:

trigger GetContacts on Accounts (after insert, after update) { for(Account a : Trigger.new){ List c = [SELECT Id FROM Contact WHERE AccountId = a.Id]; } }


GOOD CODE:

trigger GetContacts on Accounts (after insert, after update) { Set ids = Trigger.newMap.keySet(); List c = [SELECT Id FROM Contact WHERE AccountId in :ids]; }


Avoid DML operations in for loop


BAD CODE:

trigger UpdateContacts on Accounts (after insert, after update) { for(Account a : Trigger.new){ List cl = [SELECT Id, LastName FROM Contact WHERE AccountId = a.Id];

for (Contact c: cl){ c.LastName = c.LastName.toUpperCase(); }

UPDATE cl;

} }