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.
.