APEX is a development language similar to JAVA, that is used to build advanced automation in Salesforce Platform. As any of other language out in the world, some guidelines and code conventions has to be followed in order to build high quality applications.

Guidelines

As a former Java developer, I will stick to the code conventions for the Java programming language that you can find here, quite old but still a must know. Another point is that everything should be written in English, from code comments to method and class names following Camel Case. Some can find this very questionable, but from my point of view, software must be fully in English for the good and the bad that it will bring :D.

Class Header

A class must have a header at the top of it. It should be bring a description on the purpose of the class and useful information for every other developers to understand what is developed and how. Every time there is a huge modification on the behavior of the class, it should be mentioned in the header.

/**
 * @author FirstName LastName
 * @date dd/MM/yyyy - Creation
 * @date dd/MM/yyyy - author : Modification for XXX
 * @description ClassName – Functionalities description
 */

Some could find useless to specify the author as it can change very often and it’s not some information we can rely on to ask the how and the why as many could have work on the class. This kind of information can also be found and be more reliable on a GIT repository. But, I will continue to stick with this approach to have a quick overview and a guideline that will be shared across the entire project. Moreover, it will be very useful if you want to generate an ApexDoc.

Method Header

Every method must have header explaining the purpose of the method and bring information on every input and output.

/**
 * @author FirstName LastName
 * @date dd/MM/yyyy
 * @description Describe the functionality (tag the user modifying the method and why)
 * @param param1Name Description of the parameter
 * @param param2Name Description of the parameter
 * @throws ExceptionName Description
 * @return returnType Description of the returned element
 */

Code Line Comments

It’s crucial to have code line comments to have a good maintainability over the entire application, which will help developer to understand quickly what is done and communicate on any constraints or workarounds that he may have used to overcome a particular situation (Design, Governor limits …). Generally, code should be understandable without a need to massively comment every thing. Class name, method name, variable name, code structure should be explicit and so you that you only need to comment what is really matters, no comment for comments.

//User Trigram_Date_[artfXXXXX] PUT HERE YOUR LINE COMMENT BEFORE THE CODE WITH THE ARTIFACT NUMBER,  IN  LOWERCASE
for (Integer i=0; i<10; i++){...}

Formatting

public with sharing class MyExample{
    public static final String MY_CONSTANT_EXAMPLE = 'Example';

    public static String getMyExample(Integer nbVotes){
        String myExample = 'Example 2';
        
        if (nbVotes > 1){
            return myExample;
        }

        return MY_CONSTANT_EXAMPLE;
    }
}

Keep in mind that the number of characters allowed for apex coding is limited, so you should optimize the way you write your code as well as the naming of each component while keeping them intelligible.

Visualforce

Hard-coding

Hard-coding is strictly prohibited. There are variables that are independent from your org setting and other that are dependent of. Common issues that we can see is around Picklist values, URL, Profile name and Id, RecordType Name & Id … It exposes application to maintenance issues, duplication, and security breach.

Unit Test

Unit testing must prove that code is behaving the way it has been designed in a functional and technical perspective.

Remember that in order to deploy your components to production, the global coverage must be at least 75%, global means:

• The global coverage of you current production is at least at 75%
• The global coverage should rise to reach 100% and never decrease, nor go below 75%
• The coverage of triggers must rise to 100% and never be less than 1%
• The coverage of process builder and flows must rise to 100% and never be less than 75%
• When deploying, the coverage is only calculated for the component inside

Error Handling

Error handling must be part of every development. It implies sometime to have a framework to handle generic situations or a case by case resolving. It should allow total or partial rollback, to alert to users, automatic replay, to store error in a table or field for post treatment.

The 2 main objectives of error handling are:

• Ensure that database will always stay in a coherent state while errors are occurring during a transaction
• Ensure there is a simple safe way to proceed “recover on error” by storing error details and giving a way to relaunch the process

Hiding an exception is also prohibited, better let the exception to be fired and propagated automatically or manually, here are 2 bad practices that we often see:

//Silent catching of exception without handling
try {
    something
}catch(Exception e){
}

//Silent catching of exception with useless system.debug
try {
    something
}catch(Exception e){
    System.debug('## APxxx '+ e.getMessage()+ ', Error :=' + e.getTypeName());
}

The first one can make error undetectable and can put database in an unexpected state as the transaction will continue “without errors”. The second one is only detectable if you track the user, but it’s like searching a needle in a haystack.

As a best practice, I will recommend you to:

• Use savepoint to rollback to a coherent state
• Use a framework to log errors in database or external system for post treatment
• Monitor your batch process that can be prone to errors because of data volume
• Implement a replay system when you deal with Webservice calls in your transaction as the webservice call cannot be rollback easily. Replay can be total or partial, you have to handle the step from which it has to be done

I will try to cover all these in another article, so just be patient :).

Principal Rules

Conclusion

The objectives of this article is to give you an overview of the basics, some articles have already covered some points, other articles will cover the remaining points in details, just wait for it.

Hope you enjoy reading this article, see you soon for the next one ...