Coding standards - APEX

The applications works best only if it coded properly, "properly" does not mean that it just does the job well, but easy to debug, maintain, readable so that any developer can understand it.

Coding standards are great — but how do you decide which standards you want to apply, and how they will be defined? When you formulate your ideal coding style, you should think about these points:

Can you actually read the code? Is it spaced out clearly?

• Do you separate blocks of code into ‘paragraphs’ so that different sections are easily defined?
• Are you using indentation to show where control structures (if, else, while and other loops) begin and end, and where the code within them is?
• Are your variable naming conventions consistent throughout the code and do they briefly describe that data that they’ll contain?
• Are functions named in accordance with what they do?
• If you come back to the code in a few weeks or months, will you be able to work out what’s happening without needing to look at every line?
• How are you commenting the work?
• Have you used complex language functions/constructs that are quicker to write but affect readability?

Be it your APEX trigger or classes it should follow the below coding standards, which we make a developers life easy.

Proper Comments for the class/trigger:

/** --------------------------------------------------------------------------------------------------

* Class/Trigger Name : 'xxxxx'

* Description of the class/trigger

* @author      Name of the user created the class

* @version     %I%, %G%

* @since       1.0 

------------------------------------------------------------------------------------------------------**/

Proper Comments for the instance method:

Let us consider a method which updates opportunity with few parameters

eg:  public PageReference updateOpportunity(String stageName, Date closeDate)

Comments for the above method

/**

 * Updates the Opportunity

 * @param  stageName 

 * @param  closeDate

 * @return Redirect to a Opportunity Record

 */

Naming a Trigger:

<ObjectName>Trigger

For account, the trigger name should start in uppercase. eg: AccountTrigger

It is always best approach to have one trigger per object.

Naming a trigger Handler Class:

<ObjectName>TriggerHandler

For the class which handles the AccountTrigger functionality, the name should start in capital letter eg: AccountTriggerHandler

Name a Unit Test Class for Trigger:

<ObjectName>TriggerTest

For AccountTrigger, the name should start in capital letter. eg: AccountTriggerTest

Naming a Controller:

<ObjectName><Functionality>Controller

For a controller which search for list of opportunity records. The controller name should start in capital. eg: OpportunitySearchController

Naming a Unit Test Class for Controller:

<ClassName>Test

For OpportunitySearchController, the name of the test class should start in capital eg: OpportunitySearchControllerTest

Naming an Extension:

<ClassName>ControllerExt

For a controller extension which is used for OpportunitySearchController class, the name should start in capital letter, eg: OpportunitySearchControllerExt

Naming a Unit Test Class for Extension:

<ExtensionName>Test

For OpportunintySearchControllerExt, the unit test class name should start in capital. eg: OpportunitySearchControllerExtTest

Naming a Batch Class:

<Object><Functionality>Batch

For a batch class which makes a API callout retriving data from Opportunity object, the class name should start in capital. eg: OpportunityAPICalloutBatch

Naming a Schedule class:

<Object><Functionality>Scheduler

The class name should start in capital eg: OpportunityAPICalloutScheduler

APEX instance variable:

Naming an APEX variable:

APEX class instance variable should follow the camel case. And the variable named should be meaningful, by the name of the variable it should understood what purpose it is declared for. 

eg: Let us consider we are using opportunity object and performing a search to get high potential opportunity

List - highPotentialOpportunityList

Set - highPotentialOpportunitySet

Map - highPotentialOpportunityMap

Things to be considered while using the APEX instance variable:

• Declaration vs instantiation - Since it has slight effect on the performance of the system.
• Variable scope
• Access level. 

Naming an APEX instance method:

APEX instance method should be named in camel case. The name of the method should be meaningful and should say the purpose of the method for which it is used. 

eg: Let us consider a method which updates Opportunity and the name of the method should be updateOpportunity()

General things to be consider while writing APEX code:

• Querying in trigger - Make sure no SOQL in placed inside for loop.
• Bulkify your triggers using Set and Map.
• Avoid SOQL injection
• Declare variable as transient to reduce view state.
• Avoid DML statements inside loops. 
• Avoid hardcoding values and Id's
• Have one trigger per object. Keep the logics outside trigger and write it in a handler class.
• Write test code and make sure it covers 100% test coverage. 
• Instead writing the same code again and make sure write a common method to reuse it to reduce the problems in code base.
• Indent the code properly. 

Happy APEX Coding!