Salesforce Standards

Comprehensive coding standards for Salesforce development, including project code prefix naming, Apex, Lightning Web Components, and testing

Category: Salesforce
Tags: salesforce standards apex lwc testing naming prefix

This section contains comprehensive coding standards and best practices for Salesforce development within your Salesforce project or codebase.

Overview

These standards ensure consistency, maintainability, security, accessibility, and quality across all Salesforce code. All code must comply with these standards and pass Salesforce Code Analyzer validation using the project's ruleset.

Browse the hubs below for Apex, LWC, testing policy, and Code Analyzer setup. Each hub links to focused topic pages (naming, security, testing, and so on) so you are not scrolling through one giant document.

Available Standards

  • Apex Coding Standards - Backend patterns: naming, null handling, security, methods, documentation, code quality, Apex testing, and maintenance.
  • LWC Coding Standards - Frontend patterns: structure, component API, templates, data and platform, lifecycle, accessibility, CSS, LWC testing, and related topics.
  • Testing Policy - Org-wide coverage expectations, the 1:1 test-method principle, CI expectations, and links to Apex and LWC testing guides.
  • Code Analyzer Compliance - Installing and running Salesforce Code Analyzer against your team ruleset.

For a flat list of every Salesforce standards page, use the sidebar navigation or the category/tag indexes.

Project code prefix

Naming across Apex, Lightning Web Components, and tests should follow one team-chosen prefix so first-party code is easy to spot and stays consistent. The subsections below describe how to choose and record that prefix and how it maps to metadata. Format details and exhaustive examples appear in the Apex, LWC, and Testing hubs in Available Standards.

Purpose

A project code prefix identifies first-party code in a Salesforce org. It helps teams:

  • Recognize your application or package code at a glance in Apex, LWC, and related metadata
  • Reduce name collisions with standard APIs, other in-house teams, and managed packages
  • Keep naming consistent across layers (Apex, UI components, tests)

This section describes how to pick and document that prefix.

Choosing a prefix

Use a deliberate, team-level decision—not an ad hoc abbreviation per developer.

  • Represents the program, not a person. Prefer a product line, program name, or internal package identity rather than individual initials.
  • Keep it short and stable. Renaming global Apex and wide-spread LWC bundles is costly; expect the prefix to last for years.
  • Check for clashes in your org. Before locking it in, scan existing Apex classes, custom objects, labels, and major managed packages for similar prefixes or confusing overlaps.
  • Avoid platform-like tokens. Do not mimic names that read as Salesforce platform or system utilities (e.g. overly generic SYS, single-letter ambiguity).
  • Multi-package orgs. Decide whether one shared program prefix applies across packages or each unlocked package gets its own prefix—and document that rule.

Recording the decision

Maintain a single source of truth (engineering handbook, repo README, internal wiki, or ticket archive) that includes at least:

  • The Apex prefix in ALL_CAPS (e.g. ACME)
  • The LWC leading segment in camelCase (e.g. acme), used as the first segment of bundle names
  • Effective date and optional owner (team or architect)
  • Change policy: prefix changes should be rare; if they occur, document whether the change applies to new code only or includes a migration plan

How it maps to metadata

Align the same logical project across types using these conventions:

Area Convention
Apex classes <APEX_PREFIX>_<DescriptivePascalCase> with APEX_PREFIX ALL_CAPS, then underscore and name (e.g. ACME_AccountService)
Custom Apex exceptions Same prefix rule (e.g. ACME_ValidationException)
Apex test classes <APEX_PREFIX>_<ClassUnderTest>Test (e.g. ACME_AccountServiceTest)
LWC bundle / folder Leading camelCase segment from the same project (e.g. acmeDetail, acmeLookup); composition examples use exampleParent / exampleChild
LWC JavaScript class PascalCase type name reflecting that segment (e.g. AcmeDetail, AcmeLookup; composition examples use ExampleParent, ExampleChild)
Imports and tags Follow LWC naming (e.g. c/exampleUtils, <c-example-child>)

LWC bundle prefix: The first segment must be lowercase in the bundle name so the generated c-* tag in the DOM stays readable. See Project code prefix in the LWC standards. Wrong capitalization in the bundle name yields awkward tags (e.g. c-a-c-m-e-component-name).

Examples in this documentation

Standards in this site use ACME, ACME_, acme, and Acme* (e.g. AcmeDetail) as placeholders for your team’s Apex prefix and LWC segment. Parent/child composition examples use exampleParent and exampleChild so structure is clear without tying samples to one product prefix. Substitute your team’s real names everywhere.

Change History

Version 1.0 - 2026-03-26

  • Added initial version history tracking for this document.

Last Updated: 2026-03-26 Version: 1.0