Code style and enforcement lint(er) tool
- Status: proposal
- Type: Recommendation
- Start Date: 2017-02-23
- Discussion: https://github.com/QuickenLoans/js-concord/pull/10
- Supersedes: none
- Superseded by: none
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.
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.