All New Salesforce Developers Should Read This Article

It all started when I was working on my very first project as a Salesforce Developer. I was new to the platform. I had no clue that Salesforce had a set of guidelines that can help improve not only the code but also the performance and optimization of the application that we code. When I got the feedback from my leads, I realized that I need to horn my skills by knowing the best practices of Apex Coding in Salesforce. When I started to research the topic, my first stop was the list of rules that a Salesforce Developer need to know before he/she starts coding (a blog post by Kevin Poorman). It helped me on a long run and still following it as my daily work mantra. Being a lead myself, I come across many junior developers inadvertently missing out on these nuances (not intentional but because of ignorance about these thumb rules).

So, if you are a developer then you must be forced to read these Commandments…Lol   …Do not worry, I’ll be there, guiding you, throughout the journey. So, bear with me, mates.

Say ‘NO’ to queries inside the loop

Hope you all are aware of the Salesforce governor limits! These are the limits which are put on by Salesforce on the platform so that the developers don’t monopolize all the resources in the instant.

So, this commandment tells you to maintain the governor limits. This definitely initiates a good coding habit. This is due to the fact that there is always a limit of the ‘for’ loops you can apply to every account and more we put, the more mind-boggling it gets.

If you reach that limit then you will eventually end up seeing a message reading “Too many SQL queries”. DAMMMN!

So, please keep this in mind and it is in fact pretty simple to remember, I guess.

Say ‘NO’ to DML statements inside a loop

You know what an Apex DML is, in Salesforce? It is statements used for manipulation of data including insertion, deletion, merger and restoration. So, now you remember the commandment, right? RIGHT!!?

Let us tell you that why it is important. There is a limit of DML queries that you can put inside any for-loop. Once that limit exceeds…ERRR!!! The error message pops up again.

Now that is something you don’t normally wish for. You just need to pull out the DML outside of the ‘for’ loop. You know what we mean? You simply have to put the ‘List’ query before the ‘for’ loop begins and then execute the orders with another ‘if’ query after the for loop ends. Simple as that!

Keep the Balance between Clicks & Code

In many cases, you see Salesforce architectural designs with 100% codes and then there are designs with nothing but declarative interfaces. Declarative triggers like Roll-up summary fields, workflows, global settings and email templates can really improve the appeal of the interface which codes alone cannot possibly help.

It is like cooking, isn’t it? You mix everything up to make it taste better. If you just fill everything up with codes then the interface might not be as attractive as the declarations help it to make. On the other hand, only declarations will make it harder for the user to understand the functionality.

Keep up the mix healthy enough to make the program engaging and effective and the same time. Point well noted?

Always Remember – 1 Trigger per Object!

Yes… we know that Salesforce allows you to put multiple triggers per object. But to be very honest, there is no guarantee that in what order the triggers will get executed. So, if you put multiple triggers…then BANG, your entire thing might end up in a mess.

The triggers can flip their orders thereby creating a lot of commotion. That is why it is safe to use only one trigger per object and use that to manage the execution of the program. In that way, it remains free of any hassles. And isn’t it something we all desire? What do you guys think?

DO NOT put code in triggers other than calling methods

This actually helps the trigger to remain really clean. If you are put away all your codes, outside of the methods then all the triggers remain nice and tidy. In this way, the triggers remain free from any kind of complications.

Putting codes in triggers sometimes leads to a bit of uncertainty. Now, who would want something like that? However, coding is sometimes required when calling methods are needed to be put in the triggers and also in case you need to put an execution order of the trigger.

Use Maps for SOQLs

It is a challenge for any developer when he/she faces multiple sets of queries and tied data together. So, in such cases, you should use queries, not on the list but on maps.

Still thinking about it? Well, when you are using a map then you should use ‘Id’ as a key and then the actual object we want. So, you just have to put your queries within brackets inside the maps. For Example:

Map<id,sObject/CustomObj> mapName = new Map<id,sObject/CustomObj>();

This will automatically help you construct maps with the key id and also the natural object with which you are planning to work. So, basically what I’m are trying to say that it is less complex and complicated to have a series of maps instead of jumbled up queries within one list.

But wait!!! That is not all. Salesforce always allows you to create a map from a list. Isn’t it something great? This can be easily done by putting the list as a constructor of your map.

Map<id,List<sObject/CustomObj>> mapName = new Map<id,List<sObject/CustomObj>>();

It is really very helpful for the developers. This is because mapping necessarily allows them with the ability to pull out an object and any value without having to go through the trouble of changing all the iteration of a list based query. And we are just exhausted talking about it…imagine how exhausting it would be for you as a developer.

Use the relationship fields to reduce queries

If you are into development for a while you must be aware of the customer object fields. Similarly, you will also be aware of the relationship fields.

So, whilst writing your query you can easily traverse that relationship and put it as a part of your entire query. Putting a relationship inside your query will help you from not using too many queries at a given point in time.

As you know the queries are expensive and the more you use the more complicated the execution becomes. Why are we nagging about query length? Well to be honest, just like we have Salesforce governor limits for the number of queries, there is a governor limit for CPU time as well.

So, if your query runs for really long (beyond the limit) then an error message will pop up… Which will be a total waste of time!

Aim for 100% test coverage

I know that it sounds a bit pedantic. But what I really mean is that you need to get it as high as possible. The main advantage is that you will know for sure what your code is doing and whether it matches with your expectation or not.

So, if someone comes and asks you to make necessary changes then you will know which part of the code to edit and which query to alter. This makes it easier for you to change the specific things without altering the larger chunk of data.

That is why testing is super important. Do we all agree?

If so, then let us tell you why testing is super important. Firstly, it will provide you with positive effects and help you understand the logical path of your code. Trust us! It is important to understand which part of the coding is doing what.

Secondly, it will help you to point out the negative effects. Thirdly, it will help you connect the profiles with the roles.

Write meaningful and useful test

Ahem Ahem! (In a deep voice)…tests for the sake of testing should be discouraged. Write only purposeful tests. A code can have as much as 90% of unit test coverage but if all the unit tests face assertion failure it is meaningless to have so much test coverage.

We know that Salesforce forces you to write unit tests. But it is not for Salesforce. You have to understand that unit tests are for your own benefits of writing a better code. So, write only unit tests which matter and discard the rest.

Salesforce allows you to use three assertion methods. Check the following

Assert (X==Y, “Reason for Assert failure”) 

AssertEqual (X, Y, “Reason for Assert failure”) 

AssertNotEqual(X, Y, “Reason for Assert failure”) 

In order to write meaningful tests you just make sure that maintain focus and concentrate on thing at a time.

So, that’s it for now. Hope these commandments will help you write FANTASTIC error-free codes. I will keep updating this post while remembering any more recommendations that can help you code better than ever.