====== 7.1 General Naming Principles ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]]

The team should name [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] so that their purpose is clear without requiring private knowledge from the original author. A name should help a developer or reviewer understand what the Artifact represents, where it belongs, and how it relates to the Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]].

Names should support the following principles:

  - Use meaningful names rather than abbreviations known only to one developer.
  - Prefer stable architectural or implementation concepts over temporary local labels.
  - Use consistent spelling, capitalisation, separators, and suffixes.
  - Avoid names that depend on a developer’s machine, username, local path, or personal workflow.
  - Distinguish source definitions from generated Artifacts.
  - Distinguish [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] Artifacts from [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] Artifacts.
  - Distinguish reusable support code from [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]]-specific code.
  - Distinguish Baseline [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] from local developer overrides.

The team should avoid clever names, informal jokes, and unexplained shorthand in [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] Artifacts. Names should make the implementation easier to review, reproduce, and explain.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>