Skip to main content

Naming conventions

Conventions we use for naming things consistently.

General​

Everyone has their own style when it comes to naming variables, functions, classes, and even documentation. There is no single or standard way to name your code parts. Nevertheless, it is useful to make agreements with each other regarding naming.

Use English​

All code, variable names, comments etc. are written in English.

Use a spell checker​

Install a spell checker like CSpell in your IDE to avoid typos.

Be descriptive​

Do not worry about long names. Choose clarity over brevity.

“A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.”

Robert C. Martin

Be consistent​

Use one name for one thing. Do not use names that can have more than one meaning. Align naming with the whole team, including non-technical teams (marketing, management etc.). If needed, your project can include a dictionary.

Always be affirmative​

Avoid negations such as notEditable or disabled. This adds cognitive load, having to correct for the double-negative. Use isEditable or isEnabled instead.

Don’t use abbreviations​

Generally, don't use abbreviations. Exceptions to this rule are well-known abbreviations that get used more then their full version (i.e. url, http). Also allowed are the following:

  • app for application
  • args for arguments
  • auto for automatic
  • id for identifier
  • info for information
  • init for initialize
  • min for minimum
  • max for maximum
  • param and params for parameter(s)
  • prop and props for property or properties
  • ref for reference
  • ui for user interface
  • util and utils for utility or utilities

Use verbs in your function names​

Use function names that clearly explain what they do. Function names should therefor include a verb, such as do, render, get or format.

// 🚫 Bad: does not start with a verb
const valid(value: string): boolean => {}

// ✅ Good: starts with a verb
const checkValidity(value: string): boolean => {}

Use nouns for classes, variables, properties etc.​

All non-function names should have a noun as a name.

// 🚫 Bad: class name is not a noun
class CheckValidity {}

// ✅ Good: class name is a noun
class FormValidator {}

Use prefix terms for booleans​

Booleans should start with is, has, will or should, to indicate its on/off state.

// 🚫 Bad: does not include correct prefix
const value = true;
const visible = true;

// ✅ Good: includes 'has' prefix
const hasValue = true;
const isVisible = true;

Files and folders​

Use kebab-case​

We use lower-case, kebab-case in file names.

Because some systems are, and some systems are not, case-sensitive, avoid using capitals in your file names.

Use singular names​

If a folder contains multiple files for one type, it should have a singular name. For example, a folder that contains a text input component with some helper files, the folder name should be text-input.

Use plural names​

If a folder contains multiple files of a specific type, use a plural name. A folder containing files for multiple text inputs should be called text-inputs.

Add file types​

If a file contains one single type of concept, include it in the file name, delimited with dots.

// 🚫 Bad: uses camelCase
customInput.ts

// ✅ Good: uses kebab-case and includes type
custom-input.class.ts