Skip to main content

Naming, Notation and Spelling

Consistent and clear component names help our teams to communicate more efficiently and avoid misunderstandings. Follow these principles to arrive at good component names:

Naming principles​

Inclusive​

Atlas aims to be a library that can be used by people with different background and skills. Therefore component names should possibly make sense to developers, designers, managers and marketing people alike. Go for clear and readable names rather than abstract identifiers.

For example: Button Primary instead of Component-5263.

Purposeful​

A component’s name should reflect the component’s purpose and function. This helps the whole team understand when and how to use them.

For example: Action Menu instead of Icon Item List.

Domain-Adherent​

Respect conventions from the domains we are in. This could be HTML, design systems, React, UI design etc. If there is an already widely established, conventional name for a given component, it is probably a good idea to use it instead of coming up with a new one.

For example: Radio Button instead of Single-Option-Button

Systematic​

Let component names reflect their systematic relation if possible.

For example: Button-Primary, Button-Secondary instead of Button Solid, Button Ghost.

Notation​

The component names are identical throughout the system, however, slightly different notations apply:

  • Documentation website: Title Case with spaces, eg. Action Menu
  • Figma (components, layers, frames etc.): lower case with spaces, eg. action menu
  • React: PacalCase, eg. ActionMenu
  • CSS: A combination of the name of the React component and BEM (e.g. Button--primary)

Spelling​

We stick to American English spelling for all component names and documentation. This means we write for example:

  • Dialog instead of Dialogue
  • analyze instead of analyse
  • license instead of licence