Salesforce Apex Best Practices

Apex is the programming language used in Force.com platform.  It is an object oriented language with syntax similar to Java and working like database procedures. It is a powerful language which in conjunction with Force.com platform can help to build powerful applications with development time lesser than any other platform available today. Starting code development in apex language is very easy. But we should be very careful while developing in this platform as wrong coding practices will lead to hitting governor limits in Salesforce. Below I am listing some best practices for developing in force.com platform.

• Apex is case insensitive. Try to follow naming conventions similar to Java. Camelcase can be used for variable names. It is better not to use underscores in variable names, even though it is allowed. If used, it can create confusion with field names in objects which contains underscores. Give one tab indentation as Java.
• Never use queries (SOQL or SOSL) or DML Statements(Insert, Update, Delete, Upsert) inside loops.  Apex code is running in a multi-tenant environment. So Salesforce has implemented governor limits to avoid one user consuming all resources. Below screenshot shows common governor limits in Salesforce.

You can make only 100 SOQL queries and 20 SOSL queries in one transaction. One transaction includes all the actions that are carried out in one event. If you are calling any methods in helper classes and making some queries in that method, that also will be counted against governor limit. Also you are allowed to do DML operation on only 10000 records in a transaction. If you want to do more, you can go for asynchronous execution methods like Batch classes or @Future methods. But be careful not to call asynchronous methods also inside loops.

• Bulkify all apex codes if possible. For the code to be efficient and avoid hitting governor limits in force.com platform, you have to bulkify all the codes.  For example check below code. Requirement is to update status of all child records when parent status is completed.
  
  
  
  This code may work fine initially in development if users are creating records from Salesforce UI. But if there are more than 150 child records under one completed parent record. Then this code will hit maximum number of DML queries limit. If we optimize this code we can write it as below.
  
  
  Note that query at Line number 4 will executed only once and it will pull all parent and child records.  Also there is only one DML statement at the end. If you cannot manage to achieve this through child query or relationship query, you can achieve this by using collections like Map. But you should be careful in this case, not to hit heap limit.
• Try to externalize maximum parameters. Never hard code any Ids.  Ids changes between sandboxes (different in dev and production for same record type)Usually developers hard codes some values in code like record type id. It is not advisable. If at any place it is unavoidable, use it through custom labels or custom setting. It will be helpful if later you want to change the value.
• Never use batch call or @future call or Email invocation in loops. It will result in hitting respective limits. Batches queues up usually. If more than 5 times same batch is queued up, it next queuing attempt will throw exception. Number of @future calls and email invocations that can be done in single transaction is 10. If it is in a loop, chances of exceeding this limit is very high.
• Aim 100% test class coverage. It is mandatory to have a test class coverage of 75%. But more coverage means, all functionality are working as expected. Also add proper assert statements to assert test results are coming as expected.
• Do bulk testing for triggers. If you have a trigger in any object, test it for bulk volume of records(at least above 200). This will ensure that your trigger will not fail hitting common limits. Also it ensures that your trigger is bulkified. Use organization independent test data using (seeAllData=false). It will ensure code portability between sandboxes.
• Use indexed fields in WHERE clause of your queries in triggers. If there is an object that can contain more than 100k records. This is mandatory. Otherwise your trigger will fail, when the total volume of records crosses 100k. This is applicable only for triggers. You can find the details in Working with large SOQL queries.
• Write test classes covering multiple profile scenarios. Use System.runAs() to run as different users. If any test method looks like reaching limit split it into many testmethods in on class, each covering different scenarios.
• If in any test class, user data is inserted. append time stamp also to the user name. Usually if it is not append in second deployment onwards, duplicate user name error is thrown and test classes fails.
• Use Test.StartTest() and Test.StopTest() properly to avoid hitting governor limits. If you are not trying to test triggers, keep all data insertion outside Test.StartTest() and Test.StopTest(). Test.StartTest resets governor limits. But make sure that the code that covers the class, is inside Test.StartTest().
• Go for apex coding only if unavoidable. If it can be handled in out of the box functionality like workflow rule, approval process etc, try to do in that itself.