subscribe our youtube channel popup

Salesforce Naming Conventions Best Practices

This post will discuss Salesforce naming conventions best practices and how to write a clean code. Naming conventions in Salesforce are rules to follow as you decide what to name your identifiers like class, variable, constant, method, etc. But, it is not forced to follow. So, it is known as a convention, not a rule. Naming conventions make the application easier to read and maintain.

Salesforce Naming Conventions

We spend more time reading our code than writing it. So, doesn’t it make sense that our code is clean, precise, and easy to read? A well-formatted code increases readability, understanding, and ultimately maintainability of the code base. Before staring with salesforce naming conventions, let’s talk about What is PascalCase, camelCase, SNAKE_CASE?

1. camelCase

camelCase:  Each word in the middle of the respective phrase begins with a capital letter. for example apexHours

String firstName;

2. PascalCase

PascalCase: It is the same as Camel Case, where the first letter is always capitalized. for example ApexHours.

Class UserController{ }

3. kebab-case

kebab-case: The respective phrase will be transferred to all lowercase with hyphens (-) separating words, for example, apex-hours.

<c-hello-world-form></c-hello-world-form>

4. SNAKE_CASE

SNAKE_CASE: Each word should be in capital with _ like. APEX_HOURS

private static final Integer MY_INT;

Use Post Fix / Suffix:

Consistent file naming helps keep components easy to recognize and find. Here is some example of Postfix and Suffix we are using in our project from a long time.

Functional TypeName SuffixExamples
TriggerTriggerUserTrigger
Trigger HandlerTriggerHandlerUserTriggerHandler
Trigge ActionTriggerActionUserTriggerAction
VF ControllerControllerUserController
VF Controller ExtensionExtUserExt
Service ClassServiceUserService
Model / Wrapper ClassWrapperUserWrapper
Web Service (SOAP)WsUserToolsWs
Web Service (REST)RestUserCreateRest
Email ServiceEmlSvcUserCreateEmlSvc
Asynchronous (Future)AsyncUserCreateAsync
Asynchronous (Batch)BatchUserCreateBatch
Scheduled ApexJobUserCleanupJob
Test ClassTestUserCreateTest
Queueable ApexQueUserSyncingQue
Visualforce Page-none-UserClone
Visualforce ComponentCmpUserCloneCmp


APEX Naming Conventions:

  1. Class Name:  Class names should be unique, beginning with an uppercase letter. It should NOT contain underscores or spaces (except for the prefix and suffix).  Class names should be nouns in mixed cases, with the first letter of each interval word capitalized. For Example

    ClassNamePOSTFIX
  2. Variable Name: Variables should be in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should be short and sweet and meaningful. It should be camelCase like accountList

    List<Account> accountList;
  3. Method Name: Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Whole words should be used and use of acronyms and abbreviations should be limited. Name should be camelCase like  

    showAccountDetail();
  4. Constants: The names of variables declared class constants should be all uppercase with words separated by underscores (“_”). All uppercase letters in this format: CONSTANT_NAME Example: 

    private static final String ACCOUNT_LIMIT =’10’;
  5. Trigger: <ObjectName>Trigger. This should follow Salesforce Trigger Patterns – One trigger per object.

    UserTrigger

Visualforce Pages Naming Conventions

Visualforce page names and labels should be unique, beginning with an uppercase letter. It should not contain underscores or spaces. The words should be concatenated with initial uppercase letters, and subsequent internal words should be capitalized. Whole words should be used, and the use of acronyms and abbreviations should be limited.

This should PascalCase, No underscores or spaces and use whole words, limit acronym or abbreviation like below.

AccountClone

Lightning Web Components Naming Convention

Please check this post to learn about LWC naming conventions.

  1. Html File:  Use camel case to name your component and use kebab-case to reference a component in the markup. For Example

    helloWorld.html
  2. JavaScript File: JavaScript Class name should be in PascalCase like example below
    export default class HelloWorld extends LightningElement{
    }
  3. CSS File: Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. Whole words should be used and use of acronyms and abbreviations should be limited. Names should be camelCase like  

    showAccountDetail();

CSS Class Naming Standards

  • CSS classes should be named based on the component that is being addressed
  • Any name that is longer than one word, needs to be in this format : class-name
  • Multi word name should be separated by a ” – “

Lightning Component Naming Conventions

Lightning component names must be unique. They should begin with a lowercase letter. All components should end with the suffix “Cmp”. like  

userCardCmp (Initial lower case letter and suffixed with “Cmp” ) 

Lightning Events

Lightning event names must be unique. They should begin with a lowercase letter. All events should end with the suffix “Evt” . like

userEvt (Initial lowercase letter and suffixed with “Evt” )

Amit Chaudhary
Amit Chaudhary

Amit Chaudhary is a Salesforce Application & System Architect who has been working on the Salesforce Platform since 2010. He has been Salesforce MVP since 2017 and has 23 Salesforce Certificates.

Articles: 145

10 Comments

  1. Great article! I wonder who was the person giving such names, like camel, pascal, kebab and snake 🙂

  2. When i see something with Service suffix, like UserService in example, i always want to ask, what does UserService do? Everything related to user? What if there are ton of actions, which has its own dependencies? Event if there are only CRUD actions, they also could be complicated, divided into several private methods. So instead of having UserCreator, UserUpdater and other service classes, which names are very clear about what these classes do, we have UserService, which has very questionable naming and violates Single Responsibility principle. I would not advice anyone to stick with it.

  3. For class naming conventions in context of separation of concerns (SOC) arent we missing a convention for domain classes, selector classes, Interfaces and implementations?

Leave a Reply

Your email address will not be published. Required fields are marked *