SFDC Coding Best Practice

While developing in the Salesforce cloud we ask that you follow some simple standards to help keep our organization nice and tidy. Doing so is beneficial to everyone as it will make it easier to identify which metadata goes to which apps and which functional group.

i)                General Practices

ii)              Apex Class Naming Convention

iii)             Apex Page Naming Convention (VisualForce)

iv)            SObject Naming Convention

v)              Permission Sets

vi)            Test Method

1.1   general practice

­        Description is always needed for Object, Field,Tab, Application, Workflow Rule and ALL OTHERS. If there is a description field, that's mean description is needed.

­        Always use standard functionality provided by Salesforce. Use codes only if standard functionality is not able to achieve the requirement.

­        Header and Change history is always needed for all codes. This is to help others to understand what is the code doing and what changes had been made. Always start with Header, before you start code. Always update change history , before you start change.

­        NO SQL in For Loop. SOQL 101 is the common error, due to the process had run more than 100 queries. One of the common mistakes is having SOQL in For Loop. We are restricted no SOQL in For Loop in any condition. Even though you are 101% confidence and guarantee only 1 record to be process.

­        Never hardcoded record ID. Record can be changed or deleted by someone without your notice.

­        Avoid SQL injection.

a) End user can inject code into the SOQL query causing data to be returned to be modified.

APEX

○     use the String.escapeSingleQuotes method to escape the value so the variable cannot modify the SOQL command. Example:

○

String query = ‘select id from object where field = \’’ + String.escapeSingleQuotes(value) + ‘\’’;

b) End user can inject javascript code if developer uses controller or object variable

inside javascript code.

Javascript

○    Developer should use the JSENCODE function. Example:

var x = ‘{!JSENCODE(somecontrollervariable)}’;

1.2 Apex Class Naming Convention

Naming your Apex class is as important as writing clean code. For Apex classes we ask that you follow the below standards.

[GROUP]_[APP]_[ClassName]_[Type (Ctrl,Controller,Ext,Extension ­if applicable)]_[Test (if applicable)]

Note: Try to avoid shortening the application name if possible. Classes can contain up to 40 characters in the name.

Examples:

CRMIT_ReleaseManagement_MetaFinder_Ctrl

This class is owned by the CRM IT team and is a part of the Release Management application. This specific class is part of a mini utility called MetaFinder and is a controller class to a VisualForce page.

CRMIT_ReleaseManagement_MetaFinder_Test

This class is owned by the CRM IT team and is a part of the Release Management application. This specific class is part of a mini utility called MetaFinder and is the test coverage code to the previously mentioned controller class.

Note: The Ctrl was dropped from this due to expanding beyond the 40 character limit for ApexClass names.

Global_DataTableExt

This class is a global class used by the DataTable global utility.

1.3 Apex Page Naming Convention (VisualForce)

Along with naming your Apex classes it helps to name your pages with the same format to keep them in line with the rest of the application. Doing so makes it easier to identify a page's controller and extension classes easily.

[GROUP]_[APP]_[PageName]_[VF (optional)]

Note: Try to avoid shortening the application name if possible. Pages can contain up to 40 characters in the name.

Examples:

CRMIT_RM_MetaFinder

This page is owned by the CRM IT team and is a part of the Release Management application. The page is a portion of the application called MetaFinder.

Global_DataTale_Export_VF

This page is a globally used page and is provides data table functionality. This page offers exporting and is appended with a VF to indicate VisualForce. The VF is not necessary but some developers opt to do this. Being at the end it doesn't alter the identity of the page any.

Exceptions to this standard:

There are some exceptions to this rule surrounding external usage applications hosted in Sites such as Where To Buy and Web­to­Case (and chat). Pages such as these with a large user base can use more localized names that are user friendly such as ChatLaunch, ChatHome, CreateSupportCase.

1.4 SObject Naming Convention

Naming a SObject follows the same basic structure as Apex and VisualForce pages.

[GROUP]_[APP]_[ObjectName]

Note: Try to avoid shortening the application name if possible. SObjects can contain up to 40 characters in the name.

Additionally we ask that all objects labels contain the application prefix. For example the Site Inspection application which uses the prefix SIA will have an object labeled SIA Frequency. This allows multiple apps to use the same named object without causing confusion for users in the tab list, and developers and admins in the profile and object lists.

LEGAL_ROLF_Tag__c

Examples:

This object is owned by the Legal team and is a portion of their case threading system. This particular object is used to store a custom tag data for the threads.

1.5 Permission Sets

Permission sets should be named with the below standard: [GROUP] [APP] [FUNCTION]

Permission sets should be leveraged in lieu of individual profiles.

Example: Sales SSRA CRUD ­ This name is for the Sales department supporting the Secondary Sales Rep Assignment and provides CRUD access to their application objects.

 1.6 test method

All Apex Class and Apex Trigger must having Test Method, to run unit test on the class / trigger.

Test Method cannot embedded in the actual running class. All Test Method class must having @isTest annotation. No hardcoded ID use in TestMethod.

Always create your own test data for testmethod, instead query data from instance.

Minimum code coverage for APEX Class and Trigger is 75%.

All classes and triggers must meet minimum code coverage 75%