> ## Documentation Index > Fetch the complete documentation index at: https://docs.fusioncore.us/llms.txt > Use this file to discover all available pages before exploring further. # Coding Standards > The coding conventions every fusionCore contributor follows: clean code, review readiness, API versions, and metadata naming for managed and unmanaged packages. 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 Metadata API Version 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](/developer-guide/utility-functions), the [trigger framework](/developer-guide/trigger-framework), the [event framework](/developer-guide/event-framework), and the [services](/developer-guide/services) before writing your own equivalents. ## Name Metadata Correctly 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 | Rule | Notes | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Review fusionSpan's common coding standards | General guidance for working with code at fusionSpan; see the common coding standards in Confluence. | | Keep code clean | Remove unused code, commented-out code, and debug statements before committing. | | Make code review-ready | Record a demo video, post positive and negative tests on the ticket, confirm performance (bulkified, `Set`/`Map`, minimal heap and DB load), pass PMD checks, pass all unit tests. | | Match the metadata API version | Match `sourceApiVersion` in `sfdx-project.json`; do not bump it without the package owner. | | Use the built-in infrastructure | Utility functions, trigger framework, event framework, and services. | | Prefer validation trigger units over Validation Rules | Gives you ordering and programmatic disable. If you do add a declarative Validation Rule, gate it on `Global_Validations_Enabled__c`. See [Validation Triggers](/developer-guide/trigger-framework#validation-triggers). | | Name unmanaged-package metadata | Apply the per-package prefix (e.g. `FC_EG_`) documented in the package's `README.md`. | | Name managed-package metadata | No prefix (the namespace is automatic); prefix record type API Names with `FC_`. | | Place layouts and FlexiPages in the Layouts package | Managed-package layouts are not updatable in client orgs; the Layouts package is unmanaged. | | Use Custom Labels for text | Replace hardcoded text with a Custom Label; set `protected` to `false` and add the package prefix. |