Best Practices to Write Visualforce Pages & Test Classes

Best Practices to Write Visualforce Pages:

Ø  Do not hardcode picklist in Visualforce Page, include them in the Controller instead.

Ø  Javascript & CSS should be included as Static Resources allowing the browser to Cache them.

Ø  Reference CSS at the top and Javascript at the bottom of the Visualforce Page as this provides faster page loads.

Ø  Mark Controller Variable as Transient if they are not needed between server calls. This will make your page load faster as it reduces the size of View State.

Ø  Use <apex:repeat> to iterate over large collections.

Ø  Use the Cache attribute with the <apex:page> component to take advantage of CDN Caching when appropriate.

Best Practices to Write Test Classes:

Ø  Use a consistent Naming convention using Test and the name of the class being tested.

Ø  Should use the @isTest annotation.

Ø  Test method should create all the Test Data needed for the method.

Ø  Use System.assert liberally to prove that the code behaves as expected.

Ø  Write Test Methods for both Pass & Fail for certain conditions and test for Boundary conditions.

Ø  When testing for Governor Limits, use Test.startTest and Test.stopTest and the Limit Class  instead of hardcoding Governor Limits.

Best Practices to write Apex Code & Triggers

Best Practices to write Apex Code:

Ø  Use Aysnchronous Apex(Using @future annotation) when the logic doesn’t need to be executed synchronously.

Ø  Asysnchronous Apex should be bulkified.

Ø  Apex code must provide proper Exception handling.

Ø  Prevent SOQL & SOSL injection attack by using static queries, binding variables and EscapeSingleQuotes method.

Ø  When querying large data, SOQL For loop should be used.

Ø  Use SOSL over SOQL if the requirement matches as it’s much faster.

Ø  Use Apex Limit method to avoid hitting Governor Limit exception.

Ø  No SOQL & SOSL inside for loops.

Ø  No Asynchronous method(@future) inside loops.

Ø  Do not use hardcoded Ids.

Best Practices to write Triggers:

Ø  There should be only One Trigger for each object.

Ø  Avoid complex logic on triggers. To simplify testing and reuse, trigger should delegate to Apex Classes which contain the actual logic.

Ø  Bulkify any helper classes or methods.

Ø  Triggers should be bulkified and be able to process upto 200 records for each call.

Ø  Execute DML statements using Collections instead of individual records per DML statements.

Ø  Use Collections in SOQL Where clause to retrieve all records back in single query.

Ø  Use a consistent Naming Convention using Object Name(e.g.- AccountName).

Ease Of Access While Developing Lightning Components

Problem Statement:

Whenever we are developing/debugging lightning UI components, we need to refresh our page multiple times in order to see the code changes reflected on the browser or not. This can be time consuming and sometimes confusing too.

Trick:

For development sandboxes, go to Session Setting from setup and disable Enable Secure & Persistent Browser Caching To Improve Performance checkbox. With this, all code changes will be reflected immediately on screen without any delay as we have disabled the cache.

Note:

Please do this only in dev sandboxes only as it may cause performance issues with other LEX components.