This document outlines 10 commandments or best practices for Apex development on the Salesforce platform. The commandments are presented by two technical architects and include guidelines such as keeping code simple, avoiding queries and DML in loops, only using one trigger per object, focusing on test coverage, and writing meaningful tests. It is explained that these practices should generally be followed but are not strict rules, with the exception of bulkifying SOQL and DML queries. The document provides explanations for each recommendation to help developers write efficient, scalable and well-tested code.

1. Apex 10 Commandments
James Loghry
Technical Architect, EDL Consulting
@dancinllama
Kevin Poorman
Principle Architect, EDL Consulting
@CodeFriar

2. James Loghry
Technical Architect

3. Kevin Poorman
Principle Architect

4. Commandments 1-5
Kevin Poorman

5. #1 Thou Shalt keep thy code Stupid Simple. (Kiss)

6. #1 Thou shalt keep thy code Stupid Simple. (Kiss)

7. #2 Thou shalt not put queries in for loops

8. #2 Thou shalt not put queries in for loops

9. #3 Thou shalt not put DML in for loops

10. #3 Thou shalt not put DML in for loops

11. Why bulkification?
Salesforce runs on a multi-
tenant architecture. Hence,
governor limits and bulkification
are needed.

12. #4 Thou shalt only put one trigger per object

13. #5 Thou shalt not put code in triggers other than calling
methods and managing execution order

14. Commandments 6-10
James Loghry

15. #6 Thou shalt have a happy balance
between clicks & code
– “I’ve reached the maximum number of workflows”
– Triggers that replicate declarative functionality.
• Roll-up summary
• Workflows
• Flow Triggers
– Using Custom Settings instead of constructing a map in
Apex
– Using formulas instead of duplicating fields
Know which tool
is right for the
job.

16. #7 Thou shalt utilize maps for queries when needed

17. #8 Thou shalt make use of relationships to reduce
queries wherever possible

18. #9 Thou shalt aim for 100% test coverage
In general test your methods for:
 Positive effects.
• Given proper input it should act like this.
• Not just happy path, but all logic branches.
 Negative effects.
• Given bad data it should error like this.
 Role/Profile/User effects
 Given a user with X profile and Y role it should act like this.
 Bulkification
• Load 200 or more records to test limits.

19. #10 Thou shalt write meaningful and useful tests
• Not a test without System.assert calls
• System.assert(A==B,’A does not equal B’)
• System.AssertEquals(A,B)
• System.AssertNotEquals(A,B,’A equals B, but shouldnt’)
• The more assertions the better.
• Create mock data, never rely on existing production data.
• Test all conditions, not just positive test cases
• Test one criteria per unit test.

23. #Bonus! Thou shalt feel free to break these as
wisdom merits.
After all:
 Sometimes you just need a list of Id’s
 These commandments, despite their
name, are guidelines for success, not
syntactical rules you just can’t break.
 Break them if you need to, Adhere if you
can – they’ll save you time in the long run.
Except for
bulkfiying SOQL
and DML!

24. Questions & Answers