Please follow these Salesforce Best Practices to improve our code Quality, Readability, Reusability. Also, you can use Salesforce Best Practices to optimizde our code.
- Do not place SOQL or DML(insert/update/delete/undelete) statements inside a loop
- When these operations are placed inside a for loop, database operations are invoked once per iteration of the loop making it very easy to reach these SFDC governor limits
- Solution: Move SOQL/DML out of loops
- Query: If you need query results, get all the records using a single query and iterate over the resultset
- Update: If you need to update, batch up the data into a collection and invoke DML once for that collection
- Bulkify your Code
- Using Collections, Streamlining Queries, and Efficient For Loops
- Querying Large Data Sets
- Use of the Limits Apex Methods to Avoid Hitting Governor Limits
- Use @future Appropriately
- Writing Test Methods to Verify Large Datasets
- Avoid Hardcoding IDs :
- Make sure that the helper methods are properly designed to handle bulk records
- These methods should be written to be invoked with a set of records, especially if the method has a SOQL query or DML operation
- Use the power of the SOQL where clause to query all data needed in a single query
public static void hardCodeIdExample() {
if (opp.RecordTypeId == ‘016500000005WAr’) {
//do some logic here…..
} else if (opp.RecordTypeId == ‘016500000008WAr’) {
//do some logic here for a different record type…
}
}
If you run the above code in different environments, it will fail. Then Please use this code snippet:
public static void hardCodeIdExample() {
if (opp.RecordTypeId == Schema.sObjectType.Opportunity.getRecordTypeInfosByName().get(‘Test’) ) {
//do some logic here…..
} else if (opp.RecordTypeId == Schema.sObjectType.Opportunity.getRecordTypeInfosByName().get(‘TestData’’)) {
//do some logic here for a different record type…
}
}
- Make sure that the helper methods are properly designed to handle bulk records
- These methods should be written to be invoked with a set of records, especially if the method has a SOQL query or DML operation
- Use the power of the SOQL where clause to query all data needed in a single query
- Use only one trigger per SObject Type.
- Avoid logic in the trigger
- Apex unit test should not use SeeAllData True
- Naming conventions :
E.g : public class DataClass { }
E.g. : public void testMethod() { }
E.g : Integer instanceField;
For More Salesforce Naming Conventions refer this link : Salesforce Naming Conventions
- One Assert Statement per method: Always include assert statements for both positive and negative tests.
- System.assert(condition, msg)
- System.assertEquals(expected, actual, msg)
- System.assertNotEquals(expected, actual, msg)
- Increase readability by indenting code and breaking up long lines.
- Avoid nesting loops within loops.
- Write comments with a good balance between quality and quantity (explain, but don’t over-explain). Always provide documentation comments (method and class headers). Provide inline comments only when necessary to clarify complex code.
- Break methods into multiple smaller methods if possible, making your code more modular and easier to read and maintain.
- Make reusability of Apex Code
- Code coverage
- Bulk Records
- Positive & Negative testing.
- Restricted User testing.
- One Assert Statement per method
- should not use @isTest(seeAllData=true)
- Use Database Methods while doing DML operation
- Test Multiple Scenarios
Note : If you are using Visual Studio Code as your IDE, consider using the Apex PMD extension (included in the Resources section) to automatically check your code for most best practices.
Conclusion
I hope you like this blog and if you want any help let me know in the comment section.
Stay tuned, there is way more to come! follow me on Linkedln, Instagram, Twitter. So you don’t miss out on all future Articles.
Originally published at http://amansfdc.wordpress.com on November 2, 2022.