Code Layouts and Formatting Salesforce
Amit Chaudhary

Amit Chaudhary

Amit Chaudhary is Salesforce Application & System Architect and working on Salesforce Platform since 2010. He is Salesforce MVP since 2017 and have 17 Salesforce Certificates. He is a active blogger and founder of Apex Hours.

Code Layouts and Formatting Salesforce

In our last post we talk about Naming convention in Salesforce. In this post 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....
@author            : Amit Chaudhary
Modification Log:
Ver   Date         Author                               Modification
1.0   04-01-2021   Amit Chaudhary                      Initial Version

Located in the lines above the class declaration. The special tokens are all optional.

@authorthe author of the class
@datethe date the class was first implemented
@groupa group to display this class under, in the menu hierarchy
@group-contenta relative path to a static html file that provides content about the group
@descriptionone or more lines that provide an overview of the class
  • 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
@author         : Amit Chaudhary
@description    : method to is used to create usser
@param          :
@return         : Output

In order for ApexDoc to identify class methods, the method line must contain an explicit scope (global, public, private, testMethod, webService). The comment block is located in the lines above a method.

@descriptionone or more lines that provide an overview of the method
@param param namea description of what the parameter does
@returna description of the return value from the method
@exampleExample code usage. This will be wrapped in tags to preserve whitespace

Layouts and Formatting

Some of features you need to keep in mind when you are coding

Code 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. Each level of code should begin 1 tab stop further in than the level above.

if( age > 24){
    return true;
} else {
    return false;


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);

Line Length

Make to wrap-up your code lines with in 80 characters and it visible with one page. If it a big then try to break it with below wrapping rules.

Wrapping Lines

Goal: make it readable. If it is not readable, it is not formatted properly. 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

  • Break after a comma and before an operator
  • limit lines to 80 chars.
  • 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 8 spaces instead.

Here are some examples of breaking method calls:

someMethod(longExpression1, longExpression2, longExpression3,
        longExpression4, longExpression5);

var = someMethod1(longExpression1,

Following are two examples of breaking an arithmetic expression. The first is preferred, since the break occurs outside the parenthesized expression, which is at a higher level.

Following are two examples of indenting method declarations. The first is the conventional case. The second would shift the second and third lines to the far right if it used conventional indentation, so instead it indents only 8 spaces.

Line wrapping for if statements should generally use the 8-space rule, since conventional (4 space indentation makes seeing the body difficult).


Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces “{” and “}”.)

void myMethod() {
     if (condition) {
     } else {

Blank Lines

Blank lines improve readability by setting off section of code that are logically related

  • Two blank Lines: Add two blank line between sections of a source files. Always add between Class and Interface/Wrapper Class definition in Salesforce.
  • One Blank Line : User one blank line between methods, between class level variable and method. Use between logical section inside a method to improve the readability.

Remove Debug Statements

Remove debug statements from the code once done with testing

SOQL Alignment

Split each logical grouping into it’s own line.

FROM Account
WHERE Name like '%ApexHours%'

If you are using vsCode then try to use this VsCode extension for code formatting.

Code Indentation in Developer console

The new Fix Code Formatting feature in Developer Console uses the Prettier code formatter to format your Aura components

Fix Indentation

To Indent, the code in the open file, Select the code , select Edit | Fix Indentation Or, press SHIFT+TAB.

Fix Code Formatting (supports only Aura components)

To Fix Formatting, the code in the open file, Select the code, select Edit | Fix Code Formatting. Or, press Ctrl+Alt+F.

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

Share this article


  • Curious about the Class Level Comments including modification log & creation date – why if we store everything in version control these days?

    • I totally agree with you but still lots of project are not using CI/CD and version control.

  • I’m interested to hear if you intentionally changed the example for the Method level Comment?

    I’m not sure if it would matter if you use a different value.
    – @param vs @Parameters
    – @return vs @Returns

  • Very useful! Thank you Amit 🙏

  • This is very easy to understand and well written.

Leave a reply

Keep in Touch

Subscribe for Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 3,229 other subscribers


Our Supporter


Apex Hours

Apex Hours is one stop platform to learn Salesforce skills and technology

Join our Newsletter and get tips and tricks how to explore the salesforce for free!