Monday, 13 July 2020

Code Layout and Formatting

In our last post we talk about Salesforce Naming Conventions Best Practices and this time we will talk about code layout and formatting. A good developer should strive to use a consistent layout and format. It will make the life easy for other developers and code reviewer.

Different teams and projects may have different standards and when contributing to a project, you should follow your team and company standards. I have listed a few guidelines for Salesforce Developer to format the code:-
  • Code Comments Best Practices: When any developer look into your code he should understand what is going in your code easily. Means your code should be "self-documented".
    • Class Level Comment : All Classes and Triggers should begin with a brief comment describing the functional

      Apex Class Name : MyController
      Created Date    : July 12, 2020
      Description        : This is class is used for....
      Created by         : Amit Chaudhary
      Modification Log:
    • Method level Comment : All methods must have a @Description section, describing what the method is designed to process. They should have @param section for input  parameters and @return for output.

      @Method Name    : createUser
      @Description    : method to is used to create usser
      @Parameters    :
      @Returns        : Output
  • Spaces: White space is commonly used to enhance readability. Here is one example with no spaces.
    Integer i;
    Now check below code with proper white spaces.

    Integer i;
    for(i=0; i<10; i++){
        System.debug("Value" + i);
  • Blank Lines : Blank lines improve readability by setting off section of code that are logically related.
    • One blank line
      • leave an empty line after a closing function brace
      • between the local variable in a method and its first statement
      • Method definitions within a class are surrounded by a single blank line
      • between logical section inside a method to improve readability
    • Two blank lines
      • Surround function and class definitions with two blank lines
      • Between class and Interface definitions
  • Indentation : Use four spaces per indentation level. Usually we use [Tab] key to indent, but most editors can be configured to insert spaces instead of actual tab characters.

    if( age > 24){
        return true;
    } else {
        return false;
  • Wrapping Lines : When an expression will not fit on a single line. Keeping lines to a small width allows scripts to be read in one direction (top to bottom) without scrolling back-and-forth horizontally. Break it according to these general principles
    • Limit lines to 115 characters when possible
    • Break after a comma and before an operator
    • Align the new line with the beginning of the expression at the same level on the previous line.
    • If the above rules lead to confusing code or to code that's squished up against the right margin, just indent spaces instead. 
  • Placement : Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces "{" and "}".) 
    void myMethod() {
         if (condition) {
         } else {
  • Remove Debug Statements :  Remove debug statements from the code once done with testing.
  • SOQL : Split each logical grouping into it's own line.

    SELECT Id,
    FROM Account
    WHERE Name like '%ApexHours%'
    LIMIT 10

Feel free to provide more best practices. I would love to add those in this blog post.

No comments:

Post a Comment