Naming conventions

Rules

General

• Names should describe role, not appearance or context that is too specific (e.g. .menu_primary, not .menu_large or .menu_header)
• Names should begin with 'what' and follow with any descriptors, from least to most specific
• Names should be as short as possible but as long as necessary for clarity
• snake case should be used (e.g. example_component)
• distinct sections of names should be separated by a double underscore (__)

Classes

• Classes that describe context (such as state) and have no styles independent of other selectors should be prefixed with _ (e.g. ._open)
• Utility class names should be prefixed with an abbreviation (preferably 3 letters) of their type, followed by a __ separator. Some common types include:
  • Margin (mrg__)
  • Padding (pad__)
  • Text (txt__)
• If the utility class contains subtypes, the prefix should include a second abbreviation (preferably 1 letter, or 3 if more clarity is needed) of that subtype. The different abbreviations should be separated by _. Some examples of subtypes are:
  • Margin X-axis (mrg_x__)
  • Padding Top (pad_t__)

Files

• Partial files should be prefixed with _

Variables

• Variable name should be prefixed with an abbreviation (preferably 3 letters) of their type, followed by a __ separator. Some common types include:
  • Color (clr__)
  • Font (fnt__)
  • Path (pth__)
• If the variable type contains subtypes, the prefix should include a second abbreviation (preferably 1 letter, or 3 if more clarity is needed) of that subtype. The different abbreviations should be separated by _. Some examples of subtypes are:
  • Font Family (fnt_f__)
  • Font Weight (fnt_w__)