10 Quick-Fixes to better your SFDC code!

As a SFDC developer, you are expected to create magic with every line of code that you write! Your code is expected to be clean, optimized, and all of this within the time-frame set by your Project Manager and/or client! Easier said than done! Getting a perfect code in place, which adheres to all the best practices laid down by Salesforce is much like an art that is perfected with a lot of practice over time. Notwithstanding that fact, here are 10 quick-fixes to get you started on the right course, which help you stay within the governor limits and enable you to better the performance of your code without much ado.

1. Use JavaScript & CSS as static resources.

Why: So that your browser caches them and they can be reused.

2. Reference CSS at the top & JavaScript at the bottom of your Visualforce page.

Why: For faster page loads.

3. Mark your controller variables as ‘transient’.

Why: Marking your controller variables as transient reduces the size of your view state considerably, thus leading to faster page loads. Salesforce recommends to keep the view state size under 135 KB.

4. Avoid DML operations in for loops.

Why: Your code runs faster and has lesser probability to hit the Salesforce governor limits! When you use a query inside a For loop, it is executed for each iteration of the For loop and governor limit is easily reached.

5. Use WHERE clause.

Why: So that you do not end up fetching all the records, and fetch only the required ones, leading to faster processing time.

6. Reload only that part of your Visualforce page that is required.

Why: Use re-render and Action:region to reload only the required portion of the page, resulting in faster page loads.

7. Use proper and user-friendly error messages.

Why: Use of System.debug and proper error messages reduce debugging efforts considerably. Additionally, for any UI related development, error messages should be simple and crisp for easy understanding.

8. Use Test.startTest and Test.stopTest.

Why: Salesforce resets the governor limits for any code that you write between Test.startTest and Test.stopTest, so you do not face deployment failures due to exceeding the limits for that piece of code.

9. Create your own test data.

Why: If you use dummy data and move it to production, and you have not enabled ‘See All Data’, you would face deployment failures.

10. Ensure proper code comments.

Why: So that you spend minimal time on knowledge transfer pertaining to your code!

Here are some additional principles that will help you on your path for success with Apex code. So get going and start writing efficient, scalable code! May the Force (.com) be with you!