1. Whenever writing test methods (for any test class) make sure test data is created from a single location. Factory pattern is the example. By following this way, if any validations are added to an object, same can be tackled without breaking any code.
2. Try using standard set controller pagination option provided by Salesforce when doing pagination. Now we have also got OFFSET keyword which enables pagination using soql Query.
3. Only one trigger should be present for an Object. This helps us in having control over the execution of trigger.
4. Never write business logic in the trigger. Always delegate it to other classes
5. Use SOQL for loop while iterating over large amounts of data. This helps in keeping heap size in check.
6. If you are sure that you need to have a map with Id as key and Value as the respective SObject, consider using Map soql Query syntax. This helps in eliminating lots of code and thus saving lot of script statements.
Example Map<Id,Account> m= new Map<Id,Account>([select id from Account])
7. While in trigger if there is an expection, never try to catch and suppress that exception. Always throw it to the main class. It is the responsibility of the main class to analyze that exception and decide whether to suppress that or ask for user intervention
8. I suggest maintaining an exception table and logging all those exceptions in that table. This helps us in debugging while working on Namespace orgs
9. Use transient keyword liberally in visual force pages. This helps in reducing the view state of the page. Especially in the case of document uploading use of transient is a must.
10. Why we write test methods-Because Salesforce test their new release code against the test methods to make sure new version doesn’t break old version. So if there are no assertions then Salesforce doesn’t know if the code is working or not. So please make sure assertions are done in test methods. It helps a lot in regression testing.
11. While writing dynamic queries please be sure if it works if uploaded to a namespace org. This problem could occur when using Maps in visual force pages. This would work in developer org ,but fields need to be appended with proper namespace when working on packaged orgs
12. When working on Visual force pages, all CSS should be on the top of the page and the script tags at the bottom of the page. This helps in improving the performance of the pages.
13. Always consider using cache attribute on the V.F page if the page is not dynamic in nature.
14. Even when a property on the vf page is set as private it will be a part of Visual force page view state though not accessible to the page. So, please avoid using private properties if not necessary.
15. It is not advisable to use soql queries in getters and setters. This would hamper the performance of the page.
16. While working on workflows, make sure fields on workflow rule are not dependent on another workflow rule. If there is an overlap, system doesn’t have any control on which workflow executes first and which next.
17. When using variables which are not local to a method, and not needed for further processing make that value as null. This would release a lot of heap size. Batch is one of the places where we should consider this.
18. While using batch apex, only get the ids in the query locator method. Other fields required for query should be queried later in the execute method. There is check on the time taken for the query locator to execute. Hence this best practice.
19. When using email service to call an internal Salesforce class, make sure subject is consistent in sandbox and production orgs. Doing some kind of processing based on subject should not break any code. If there is any discrepancy, put your subject into a predefined bracket and search for that position to extract exact information to do further processing.
20. While doing any data load take care of the fact that it doesn’t trigger any unnecessary emails to the recipients. Even when some of the time based workflows are deactivated, items already present in the time trigger queue will be processed. So care should be taken they are also removed from the queue.
21. When working on VF pages, use void methods for in-between Ajax calls and Page Reference method for final call. When using page reference return type on complete attribute doesn’t work as the system assumes that code redirects the page to some other url.
22. If maintaining view state on the page is not a main criterion, always go with Java script remoting. Java script remoting is fast, and developer has better control on the results that are returned
23. Use Firebug mode on Firefox, or developer tools on chrome to understand the whole life cycle of the page. It also helps in debugging browser compatibilities.
24. Always use enums and labels while working with exceptions.
25. Load all the data required for processing into the memory and then process the data already available in the memory. This helps in reducing the number of soql queries used. Practice using relationship queries. Triggers is one place where most of the refactoring of the code can be done using this approach
26. Reverse engineering always helps in better assessing the best way to accomplish the things. Let’s say there is some account data that need to be validated against the existing data belonging to the same object.
One way of doing this is writing multiple queries with where clause changing all the time. Other way is use a single query get all the required data, then match just against the fields. This approach can be used in survey deployment module where multiple queries are used to check which survey should be deployed to the user. Because of this only 100 surveys can be deployed to a user.
27. Consider using apex: actionsupport if it does your work. Never go with apex: action function. There is performance related mechanics that makes apex: actionsupport the best bet.
28. Query only the fields that are required. Never query unnecessary fields.
29. Master Map, set and list. These are the building blocks of Salesforce.
