Salesforce Apex Coding Standards

                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