Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
94 lines (62 sloc) 2.83 KB

Code style and enforcement lint(er) tool


Define a recommendation for JavaScript coding style and a lint(ing) tool.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


The goal is to achieve a consistent code-editing experience across many projects. A single style should be followed so that code written for one project will "look" as if it was written in/for any other project. It should be hard to distinguish code written by different developers. This should promote people contributing to other projects directly or through "sharing" code.

Choosing a single lint(ing) tool/utility will simplify dependency footprint and enable people to share knowledge or project configuration. Further, this will enable projects to have a more consistent tool-chain and be built from a common starting point.


The recommended coding style for JavaScript is the AirBnB JavaScript Style. The lint(ing) tool to enforce the style is ESLint.

Projects should include, as a dependency, the eslint-config-airbnb and configure ESLint to enforce those rules.


  • Restriction - some developers might feel that a standard like this prevents them from writing, "the way they like to"; to some extent that is exactly true.
  • Onboarding - when new people join the team these decisions might need to be (re)justified or, possibly, defended.
  • Position - defining/adopting a standard puts a target on us for making the decisions that we have/will.


Code Style (alternatives)

Lint(er) (alternatives)

Unresolved (questions)