Force.com Programming Best Practices

Apex

• Since Apex is case insensitive you can write it however you’d like. However, to increase readability, follow Java capitalization standards and use two spaces instead of tabs for indentation.
• Use Asychronous Apex (@future annotation) for logic that does not need to be executed synchronous.
• Asychronous Apex should be “bulkified”.
• Apex code must provide proper exception handling.
• Prevent SOQL and SOSL injection attacks by using static queries, binding variables or the escapeSingleQuotes method.
• When querying large data sets, use a SOQL “for” loop
• Use SOSL over SOQL where possible – it’s much faster.
• Use Apex Limits Methods to avoid hitting governor exceptions.
• No SOQL or SOSL queries inside loops
• No DML statements inside loops
• No Async (@future) methods inside loops
• Do not use hardcoded IDs

Triggers

• There should only be one trigger for each object.
• Avoid complex logic in triggers. To simplify testing and resuse, triggers should delegate to Apex classes which contain the actual execution logic. See Mike Leach’s excellent trigger template for more info.
• Bulkify any “helper” classes and/or methods.
• Trigers should be “bulkified” and be able to process up to 200 records for each call.
• Execute DML statements using collections instead of individual records per DML statement.
• Use Collections in SOQL “WHERE” clauses to retrieve all records back in single query
• Use a consistent naming convention including the object name (e.g., AccountTrigger)

Visualforce

• Do not hardcode picklists in Visualforce pages; include them in the controller instead or you can use Custom Settings for larger picklist values.
• Javascript and CSS should be included as Static Resources allowing the browser to cache them.
• Reference CSS at the top and JavaScript a the bottom of Visualforce pages as this provides for faster page loads.
• Mark controller variables as “transient” if they are not needed between server calls. This will make your page load faster as it reduces the size of the View State.
• Use to iterate over large collections.
• Use the cache attribute with the component to take advantage CDN caching when appropriate

Unit Testing

• Use a consistent naming convention including “Test” and the name of the class being tested (e.g., Test_AccountTrigger)
• Test classes should use the @isTest annotation
• Test methods should create all data needed for the method and not rely on data currently in the Org.
• Use System.assert and System.assertEquals liberally to prove that code behaves as expected.
• Test each branch of conditional logic
• Write test methods that both pass and fail for certain conditions and test for boundary conditions.
• Test triggers to process 200 records – make sure your code is “bulkified” for 200 records and doesn’t throw the dreaded “Too many SOQL queries: 21″ exception.
• When testing for governor limits, use Test.startTest and Test.stopTest and the Limit class instead of hard-coding governor limits.
• Use System.runAs() to execute code as a specific user to test for sharing rules (but not CRUD or FLS permissions)
• Execute tests with the Force.com IDE and not the salesforce.com UI. We’ve seen misleading code coverage results when running from the salesforce.com UI.
• Run the Force.com Security Source Scanner to test your Org for a number of security and code quality issues (e.g., Cross Site Scripting, Access Control Issues, Frame Spoofing)

For Reference:

• CRUD, FLS and Sharing
• Force.com Apex Code Developer's Guide
• Security Tips for Apex and Visualforce Development
• Cloud Security - salesforce.com