Every fusionCore package follows the same coding conventions so the codebase stays consistent, performant, and reviewable across teams. This page collects those rules. Read it alongside fusionSpan’s common coding standards in Confluence, which cover the general guidance for working with code at fusionSpan; the rules below add the fusionCore-specific expectations on top of that baseline.
Keep Your Code Clean
Before you commit, tidy up the changeset:
- Remove unused code.
- Remove commented-out code.
- Remove debug statements.
Make Your Code Review-Ready
Work through this checklist before you submit a change for review:
- Record a short video of the feature showing the intended use case.
- Post a list of the positive and negative tests you ran for the feature on the ticket.
- Make sure the code is performant. It should be bulkified, use
Set, Map, and other data structures to reduce CPU time, and minimize heap and database load through cache methods and carefully crafted SOQL.
- Run PMD checks and make sure they pass. The current rulesets live in the
pmd-rulesets repo in Bitbucket.
- Run all unit tests and make sure they pass.
Match the API version of any metadata you create to the sourceApiVersion field in the package’s sfdx-project.json, for example "sourceApiVersion": "65.0". In almost all cases your code should match this value.
Do not bump sourceApiVersion without talking to the package owner. Older packages may sit on an older version on purpose, and the team usually updates all of a class’s metadata at the same time. Some packages are older than others, so the value differs from package to package.
Use the Built-In Infrastructure
Build on the shared platform infrastructure instead of reinventing it. Reach for the utility functions, the trigger framework, the event framework, and the services before writing your own equivalents.
How you name metadata depends on whether the package is managed or unmanaged. You can tell which a package is from the namespace field in its sfdx-project.json: a populated namespace string means the package is managed, while an empty or missing namespace means it is unmanaged.
Unmanaged Packages
Metadata in an unmanaged package carries a per-package prefix, for example FC_EG_MyApexClass or FC_EG_MyObject__c. Find the prefix for a given package near the top of its README.md, under the Development Conventions section.
Managed Packages
Do not add a prefix to metadata in a managed package — Salesforce adds the namespace automatically. There is one exception:
- Record types — prefix the API Name (
DeveloperName) with FC_. For example, a record type with the label Miscellaneous has the API name FC_Miscellaneous.
If you add formula fields, or links to pages, inside a managed package, include the namespace where appropriate.
Place Layouts and FlexiPages in the Layouts Package
Put layout and FlexiPage changes in the Layouts package rather than in a managed package. Managed-package layouts are not updatable in client orgs, so a layout shipped inside a managed package cannot be changed after install. The Layouts package is unmanaged, which means its layouts remain editable. Implementers should make copies of these layouts to avoid upgrade issues.
Use Custom Labels Instead of Hardcoded Text
Wherever you display hardcoded text, create a Custom Label for it instead. Set the label’s protected field to false so the implementation team and admins can modify it, and add the appropriate package prefix.
Rules at a Glance
