Naming Principles

Apply these when creating or evaluating any naming standard.

Principle	Description
Clarity	Names should be immediately understandable. Avoid abbreviations, indirection, and jargon. If a reader has to guess, the name has failed.
Qualification	Every resource should identify what it is at a glance. A repository named reporting could be a service, a schema, or a report archive — that ambiguity has a cost. Qualification can come from context, but when in doubt, be explicit.
Consistency	The same concept should always have the same name. Consistent names are predictable names, and predictable names are discoverable — a developer should be able to guess the name of a resource they've never seen before because it follows the same pattern as everything else.
Uniqueness	Names must be unambiguous within their scope. Determine what "unique" means for a given context and ensure the standard meets it.
Automation-Friendly	Names should work reliably with tooling. If a naming choice forces scripts or pipelines to make extra API calls or string manipulations to resolve a resource, reconsider the name.
Constraints-Aware	Every system has length limits and character restrictions. Know them before finalizing a convention. When a limit forces a tradeoff, prefer removing unnecessary qualifiers over introducing abbreviations.
Changeability	Names are hard to change. Before establishing a convention, consider what a rename would cost — blast radius, dependent systems, migration effort. The right name upfront is cheaper than the right name later.