Permalink
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

Summary

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

Conventions

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.

Motivation

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.

Design

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.

Drawbacks

  • 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.

Alternatives

Code Style (alternatives)

Lint(er) (alternatives)

Unresolved (questions)