I am a Program Architect with Salesforce Advisory Services and my role is to be my customer’s trusted adviser on all architecture issues, both specific to Salesforce and generally across their enterprise. One of my key responsibilities as a Program Architect is to mentor my customer’s Force.com platform developers by giving them constructive advice on how to write “good code”. This is to ensure that developers are writing code with an eye towards maximizing the features of our cloud-based platform and that their code is reusable and scalable, which leads to a lower overall TCO.
There are plenty of documents on coding best practices, each with their own set of recommendations, that are difficult to follow and often get lost in a development process. Also, no two developers think alike and to restrict them to a certain development practice is akin to telling an artist how to draw. So, rather than build prescriptive coding guidelines, I came up with a checklist of topics and areas that each developer needs to think about when writing code. The intent is to make developers think about best practices by asking themselves these questions and answering them, before or while writing code. Also, the list is specific to Force.com programming (Apex/Visualforce), and does not address general object oriented programming concepts like encapsulation, etc.
Downloadable copies of this list are available here: XLSX format | PDF format
Project/Enhancement Name: |
|||
Developer Name: |
|||
Date: |
|||
S. No. |
Question |
Answer |
|
---|---|---|---|
1. Visualforce |
|||
1.1 |
Why Visualforce and not standard UI |
||
1.2 |
Does it have a controller |
||
∙ Standard controller or custom controller |
|||
○ If custom controller, then why not standard |
|||
∙ Does it have Apex code (extensions for standard, or custom controller/extensions) |
|||
○ See Apex section #2 below |
|||
1.3 |
Does it have URL parameters and if so, are they escaped |
||
1.4 |
Is it mobile ready (HTML5 vs. Touch) |
||
1.5 |
Is CSRF on GET Requests Checked (v28.0 and beyond) |
||
1.6 |
Does it use custom CSS or JS libraries |
||
∙ jQuery, Angular, etc. |
|||
1.7 |
Is there opportunity for re-use using VF components |
||
1.8 |
Does it use VF templates (composition) |
||
1.9 |
Are there any dependencies on: components, other VF pages, or static resources |
||
∙ If using multiple static resources, are they zipped for performance |
|||
1.10 |
Is it embedded in a standard page (i.e. Panel) |
||
1.11 |
Is it for an action override |
||
1.12 |
Does it follow naming conventions as defined at your organization |
||
2. Apex |
|||
2.1 General Apex Guidelines |
|||
2.1.1 |
Sharing (with/without/none) |
||
∙ If without sharing, then why |
|||
∙ If none, then why |
|||
2.1.2 |
Are you using inner classes where possible |
||
2.1.3 |
Are you using custom settings or constants (FINAL) for non-dynamic variables in code |
||
2.1.4 |
Does your class have a large number of properties |
||
2.1.5 |
Do you have methods with a large number of lines (> 45) |
||
2.1.6 |
Are there any orphaned (or obsolete) classes, properties and methods |
||
2.1.7 |
Is the API version the latest, if not, then why |
||
2.1.8 |
Is code bulkified |
||
∙ No SOQL or DML statements in for loops |
|||
2.1.9 |
Are you checking for selectivity of SOQL statements using Explain Plan tool in Developer console (with at least 10k rows) |
||
2.1.10 |
Exception Handling |
||
∙ For SOQL queries and DML statements |
|||
∙ Is there a need for custom exception classes |
|||
2.1.11 |
Test methods – are they embedded in the main class |
||
∙ Should be in separate Test Classes (enforced starting with v28.0) |
|||
∙ Do test methods have assertions – positive and negative |
|||
∙ Test Data in test methods – is it generated in Test |
|||
∙ If not generated and using Org data, then why (e.g. Content) |
|||
∙ Are you using Test Data Setup Framework – part of core |
|||
∙ Use of startTest() and stopTest() |
|||
∙ Do test methods leverage different users and profiles |
|||
∙ Are you using bulk updates in test methods |
|||
∙ Are you checking for limits usage in test methods |
|||
2.1.12 |
Code & Naming standards |
||
∙ Global constants |
|||
∙ Code comments and tagging |
|||
∙ Null checks |
|||
2.2 VF Controllers & Extensions |
|||
2.2.1 |
How are fields being retrieved (addFields() vs. SOQL vs. VF Binding) |
||
2.2.2 |
Does controller have SOQL |
||
∙ Does SOQL use bind variables to prevent injection |
|||
2.2.3 |
Separation of business logic from controller |
||
2.2.4 |
Early vs. late binding |
||
∙ Late binding helps with view state management |
|||
∙ Early binding helps page load performance |
|||
2.2.5 |
Use of action attribute vs. controller constructor |
||
∙ Controller constructor runs before page action |
|||
∙ Constructors do not allow DML, have to be done in action |
|||
2.2.6 |
View state management and use of transient variables |
||
2.3 Triggers |
|||
2.3.1 |
Are you using a Trigger Handler framework wherein the business logic is separated into a separate handler class |
||
2.3.2 |
Multiple triggers on objects (should be N/A if using base) |
||
2.3.3 |
What trigger events |
||
2.3.4 |
Recursive handling |
||
2.4 Batch Apex |
|||
2.4.1 |
Are you using a framework for logging DML results using helper classes |
||
2.4.2 |
Is there an associated schedulable class |
||
2.4.3 |
Are you using daisy-chaining feature |
||
2.4.4 |
Are you using Stateful and AllowsCallouts |
||
2.5 Web Services |
|||
2.5.1 |
Are you leveraging the mock testing framework to test web services |
||
2.6 Email Services |
|||
2.6.1 |
Custom objects for logging and error handling |