Salesforce Apex Coding
Standards
Coding Style
Indentation
·
Whitespace - Since Apex is case
insensitive you can write it your way. However, to increase readability, use four
spaces instead of tabs for indentation.
·
New Line – To increase readability – Use new
line at starting point for every new block.
Naming
conventions (Pascal, Camel Case, snake_case etc.)
·
Apex Class names should be in UpperCamelCase,
with the first letter of every word capitalized.
§
Eg: AccountTriggerHandler
·
Methods should be verbs in lowerCamelCase or
a multi-word name that begins with a verb in lowercase; that is, with the first
letter lowercase and the first letters of subsequent words in uppercase.
§
Eg: getParentAccount()
·
Variables: Local variables, instance
variables, and class variables are also written in lowerCamelCase.
§
Eg: Integer index, String accountName.
·
Final Varibale should be CAPITAL. Eg: final
Integer BATCHSIZE=20.
·
Variable names should not be single
characters.
·
Test Class name should be as PascalCaseTest.
i.e. – AccountTriggerHandlerTest
·
Test method should be as testShouldExecute<ClassName>When<data>
§
Eg: testShouldExecuteAccountTriggerHandlerWhenAddresschanged()
·
Datatype should be UpperCamelCase
§
Eg: String, Integer, List, Map, Wrapper,
Account, etc.
·
Boolean values Should be CAPITAL i.e.,
TRUE or FALSE.
Minimal
comments - unless VERY temporary
ü
Remove the commented code as this is always a
blocker, while going through the code.
ü
Comments should tell WHY not WHAT.
ü
Git tracks history so no need to comment code.
Use
same conventions within a Class.
Example:
instantiating an sObject using the sObject constructor vs the object.field
notation
|
SBQQ__Quote__c quote1 = new
SBQQ__Quote__c (
SBQQ__Opportunity2__c
= opp1.Id,
SBQQ__MasterContract__c = c.Id,
SBQQ__Primary__c = TRUE
);
multiQuoteList.add(quote1);
Vs
SBQQ__Quote__c
quote1 = new SBQQ__Quote__c ();
quote1.SBQQ__Opportunity2__c
= opp1.Id;
quote1.SBQQ__MasterContract__c
= c.Id;
quote1.SBQQ__Primary__c
= TRUE;
multiQuoteList.add(quote1);
|
Doesn't matter which convention you use, just keep it consistent within
the class.
Should
not have methods with large number of lines.
ü
Make sure each method contains not more than 40
lines.
ü
If there are more lines break into multiple
methods.
ü
Classes no more than 10 methods or 300 lines.
ü
Don't add unnecessary code. Only the code needed
to achieve the feature you are working on
Break
SOQL Queries across multiple lines
·
SELECT keyword and clauses such as
WHERE, WITH, GROUP BY, and ORDER BY, etc. all should be in CAPS.
·
Need to Break/new line for each
clause.
·
List all fields in ascending
alphabetical order.
|
[ Select Id, Name, customField1_c,
customField2_c from Account where Name like '%Nave%' ]
|
·
Bad Practice
·
Good Practice
|
[ SELCT Id, Name, customField1_c, customField2_c
FROM Account
WHERE Name like '%Nave%' ]
|
No
System.debug Statements
ü
Unless you absolutely need to debug something in
Production.
ü
This also include Javascript console.log
statements in front-end code.
Coding best practices
Keep
It Simple Stupid (KISS Principle)
ü
There should be as little logic in your code as
possible.
ü
Write a single method and reduce the clutter in
your code.
ü
Simple code is easier to maintain.
ü
Bad Practice
ü
Good Practice
Don’t
put SOQLs inside loops.
ü Bad Practice
ü
Good Practice
Utilize
the Maps for Queries
ü Map<Id, sObject> myAwesomeMap =
new Map<Id,sObject>(List of sObjects or SOQL Query);
Use
relationships to reduce queries.
Don’t
put DMLs in loops.
Test
code coverage
ü
Cover as close to 100% of the code as possible.
ü
Never use dummy code coverage
Write
meaningful unit tests.
ü
Create all test data before calling the
Test.startTest method.
ü
Must have System.Assert for each test method.
ü
Include a description of expected behaviour as
2nd parameter for System.assert() or 3rd parameter for System.assertEquals()
ü
Examples:
ü
System.assert(A == B,’A does not equal B’);
ü
System.assertEquals(Expected,Actual,’Actual does
not equal Expected’);
ü
System.assertNotEquals(Expected,Actual,’Actual
equals Expected, but should not’);
Reusability
ü
Avoid duplicated code (more-so in same class
than across classes)
ü
Use existed Trigger Framework, TestDataFactory
and HTTPMOCKClasses
ü
One Object should have one Trigger only
Avoid
Hardcoding IDs:
ü Use Custom Settings, metadata types
or custom Labels. (Or)
ü Get values dynamically
ü Bad Practice
ü Good Practice
The
fewer the method parameters the better
ü Try to avoid more than 3 arguments
