Choose Naming Conventions
Learning Objectives
After completing this unit, you’ll be able to:
- Define what naming conventions are, and more importantly, what they are not.
- Recognize the value of naming conventions.
- Apply naming conventions for the most common Salesforce components.
- Identify scenarios in which it is better to deviate (partially) from naming conventions.
Street Naming Conventions
Apart from its theatre shows and pastrami sandwiches, Manhattan, a borough of New York City, is known for its street naming. Streets in Manhattan are consecutively numbered, first, second, third, and so on. Streets that run from east to west are named Street. Those that run from north to south are named Avenue. This is a good naming convention because it lets you derive basic details about the streets quickly and easily.
Naming conventions are just as useful for components in an org as they are for streets in a city. Because no developer has time to inspect every Apex class, process, and workflow in their search for the right one, consistently structured, informative names are essential. Naming conventions define a common set of rules that help you deduce useful information from the names of Salesforce components.
Success Cloud Naming Conventions
We sat down with some of the most experienced developers in Success Cloud to find out which naming conventions they use. The Success Cloud Naming Conventions Quip table outlines commonly agreed upon conventions for the most common Salesforce entities.
Naming an Apex Class
To understand how to apply Success Cloud naming conventions, let’s take a look at the naming convention for Apex classes.
| Type | Capitalization | Naming Convention | Comments |
|---|---|---|---|
| Apex Class |
PascalCase |
<Namespace>_<Class Name><Optional Suffix> |
- Namespace: See instructions following this table. - Class name: nouns in PascalCase. Avoid acronyms and abbreviations. - Suffix: Indicates common class types: Controller, Extension, Handler, Utilities, TriggerHandler. |
In general, the scope of metadata entities will be either enterprise or project. Enterprise-scope entities are used by multiple apps or modules. Project-scope entities are used only within one app. For project-scope entities, it’s good practice to define a namespace (short, often an acronym) with your team. Use a namespace only with entities that are exclusive to a single app, and will always be exclusive to that single app. In general, it’s a good practice to share resources between apps, so when you think your project-scope entity might become an enterprise-scope entity later, it’s best to not use a namespace.
Don’t confuse the project namespaces we refer to here with the namespaces of packages or dev orgs. Because projects are typically defined at a lower level than packages or orgs, you define project namespaces that are different form package and org namespaces.
Imagine you are developing a configuring and pricing tool for small businesses. The tool performs a customer assessment before generating a quote. You have created a Lightning component that performs the assessment, and you’re writing an Apex class to control the component. Being the rockstar developer you are, you want to name this class according to naming conventions.
According to this Apex Class naming convention, you should prefix the class name with the namespace of your app. It can be tempting to choose SmallBusinessConfiguringAndPricingTool for the namespace, but such a long namespace defeats the purpose of naming conventions, which is being able to see at a glance what a component is about. Thus, an abbreviation like SBCPT is a better choice. It’s succinct but still helps developers see that the Apex class is part of the configuring and pricing tool.
Next, you have to define the class name. Class names should consist of nouns only, and the key is to keep it short and simple, so you choose Customer Assessment. Because the naming convention dictates that you use PascalCase, you transform this into CustomerAssessment.
Finally, the naming convention gives you the option to add a suffix. Because this Apex class functions as the controller for your Lightning component, you choose the suffix Controller.
Now all that’s left is to glue everything together. The naming convention puts an underscore between the namespace and the class name, but nothing between the class name and the suffix. Thus, the final name of your Apex Class is SBCPT_CustomerAssessmentController.
Our Conventions, Your Conventions
The example in this unit covered Apex classes. Our team has created naming conventions for many more Salesforce entities, including approval processes, process builders, validation rules, VisualForce pages, workflow rules, and Lightning (Web) Components. We highly recommend that you bookmark the naming conventions table (or print it out, if you’re old-school), so you can find it quickly when you need it, until you become more familiar with the contents or finish defining your own naming conventions.
One final thing to remember: It’s not important what your coding conventions are. It’s important that every team member knows what they are and agrees to follow them. Our recommended conventions can be a good starting point for discussing your own naming conventions with your team or with your clients. When you talk with a client, always remember to ask whether they already have their own naming conventions in place. If they do, then you can tailor our Success Cloud conventions to the client's standards, which is better than imposing Success Cloud standards on the client.
This unit illustrated that using naming conventions holds significant benefits for you and your team. In the next unit, you learn how frameworks can increase collaboration and further improve the quality of your code.
