JavaScript

There are many flavors of JavaScript available now:

Depending on when a project was started, the tools in use, and the purpose of the project, it is likely to conform to a different code style. Thus, Vokal does not have a single JavaScript code style.

For vanilla JavaScript, and as a base for other standards, most projects should start from the Airbnb styleguide which you will most likely install from npm.

ESLint

ESLint is currently the most popular tool for enforcing code quality in JavaScript short of static type checking. All projects should have an .eslintrc file, and all engineers should configure their editors and CI to enforce the rules.

During project initiation, and as appropriate thereafter in the project lifecycle, engineers should choose a current and industry accepted set of rules that the project team agrees with. Teams may elect to make modifications to their rulesets by consensus at any time, but individual engineers on a larger team should not modify rules without team consensus.

Code must not be committed with any ESLint errors. Code should not be committed with ESLint warnings. Use ESLint ignore comments sparingly, and only with good reason.

TypeScript

The TypeScript compiler will, if in use, enforce additional criteria. Use of type annotations is recommended, particularly when code is subject to being passed between functions or between files. 100% annotation is not required.

Non-Enforceable Code and Good Taste

There are many aspects of good code that do not readily translate to specific rules, such as:

A passing ESLint config does not mean that code meets any of the above quality criteria. The pull request code review process is an excellent opportunity to get a second set of eyes on code, particularly to look for higher level quality issues.