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;
    for(i=0;i<10;i++){
        System.debug("Value"+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,
           Name
    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