Things to avoid in APEX (Part-2)

Incase you haven't seen the Part-1 of Things to Avoid in Apex, below is the link

https://adityanthiruchuri.blogspot.com/2021/08/things-to-avoid-in-apex.html

Let us understand few more tips / tricks in this post.

1. Use '==' over 'equals' whenever required

We all know that APEX is not case-sensitive.  But we need to understand that there are few methods in apex, which takes the case-type (lower/upper) into consideration.   When you use the method 'equals' it will return TRUE only if the LHS and RHS are of same value and same case-type. Look at the below example

If you still want to make use of "equals" without taking case-types into consideration you have to either use method "equalsIgnoreCase()" (or) convert both the LHS and RHS into either lower / upper case and then do the comparison, but remember that these methods wont work for "null" values.   Whereas, operator '==' does the job without any such case conversions.  Use method 'equals' to do a comparison only when you want the case-match to be taken into consideration.

2. Concatenation of Strings

If given a requirement to concatenate two strings, we all tend to use the operator '+', but what if I tell you that the method .join() consumes way lesser time than the operator '+'.. Let me elaborate by taking an example.  I am trying to prepare a String by adding all the names of Opportunities separated by a comma.  There are 8500 records present while executing the below logic.

Above code consumed CPU Time of 1049ms.  Now let me execute the same logic by getting rid off the '+' operator by using "join" instead.

Above code consumed CPU Time of just 586ms which is almost 50% lesser than the time taken by the "+" operator.  Also as you are creating a new collection variable, ensure to take the heap size to take into consideration.  You can do the above implementation in your own orgs to get the results.

3. Avoid un-necessary creation of collection variables while preparing Map

Let us take a scenario of preparing Map<Id, list<Opportunity>> where key is AccountId and value will be its associated Opportunities.  Most of us will be writing code like below

In the above logic we have created an extra list at line#6, populated it with the current iterating record and then added it to the map, so that override will happen.  We need to understand that maps are mutable and that gives us the flexibility to modify an element of a map directly without having to add it again.  Consider the logic below

By using the above approach, we completely eliminated the need of creating an extra list and using the same to override the existing value.  

4. Do not use String datatype for holding Id's

I have seen many instances where developers use data-type String to hold value of type "Id". There are many drawbacks of using that approach.  We all know that Id's can be of length 15 or 18 based on the case-sensitivity.  Let us take a simple example to understand the consequence.  I am just hardcoding for our scenario, but keep in thoughts that this is never encouraged as a practice.

Reference : https://salesforce.stackexchange.com/questions/348609/why-this-map-return-null-value/348616

We need to have our code always dynamic in nature.  We can understand from the above example that if we store 15 digit Id in a string, it will fail when used against 18 digit Id and vice-versa.  But if we use the use "Id" data-type rather than string for the above, logic works just smooth.

Hope you find this interesting.  There are still many points to add and few more will be posted soon.   Let me know in the comment section if you have any such tips.  Feedback is much appreciated and thanks for being an awesome reader.  

..Bazingaa..