Bitcrowd JavaScript Guide

Apart from our development processes and practices, we are employing additional methods for ensuring high code quality:

1. Automated Code Formatting & Linting ensure that code is written in a consistent style and conforms to pre-defined standards.
2. Tests are useful as a design tool, for documenting your code and making sure it works correctly. Good tests allow you to change your code's structure without breaking its behaviour, during refactorings for instance.
3. Metrics help you understand how code changes affect various measurable characteristics of your code.

Tool-support has gotten pretty good, so all of these are rather quick to set up. Where possible checks should be automated and have shareable configs.

Automated Code Formatting

At a very basic level, adding an EditorConfig file in your project helps keeping code formatting consistent (example). Many editors already natively support EditorConfig, for others there are plugins.

Prettier is a tool to automatically format source code. It can be integrated into your Git workflow and editor.

Note that using Prettier does not make linting obsolete. Prettier corrects code formatting issues but does not warn about code quality problems detected by many linting rules.

ESLint Configuration

Our standard ESLint configuration follows that of Airbnb and integrates Prettier.

The Airbnb configuration comes in different flavours:

1. a base configuration for ECMAScript 6+ code (and a legacy version for ES5 and below)
2. a react configuration for ES6+ linting with additional rules for React applications

Install the packages which fit your current project and create an .eslintrc.json file (example). We recommend setting "root": true so as to avoid system-specific differences in linting behaviour.

Note: If you're working on an Angular(JS) application, consider using eslint-plugin-angular.

Auto-fixing Linting Issues

Some ESLint rules support automated fixing. To apply fixes, run eslint with the --fix flag.

Directory-specific overrides

In order to adapt the ESLint configuration for parts of the project tree, you can drop additional .eslintrc files into into specific subdirectories.

ESLint will pick up these file in addition to the one in the project root via configuration cascading.

Ignoring files

You will likely want to prevent ESLint from scanning certain files, e.g. node modules and application bundles. To do so, you can either create an .eslintignore file or use your .gitignore:

eslint --ignore-path .gitignore .

Including files

If you are using file extensions other than .js for files that need to be linted, e.g. .jsx, be sure to specify them via the command line:

eslint --ext .js,.jsx .

Testing

Your code should have tests.

We're mostly using Jest which should look rather familiar if you've used RSpec or any other behavior-driven development framework before.

When you're testing React code, use Enzyme.

If you ever need a headless DOM in Node.js take a look at jsdom.

For a usage sample of Jest, Enzyme and jsdom, you can head over to the Tickety Tick repo.

Metrics

While code metrics should always be taken with a grain of salt, they can provide rather useful insights into how code changes affect code quality.

Such metrics may be derived from static analysis of the source code or even describe runtime characteristics of the software.

A metric we may want to use more often is code coverage. Jest has support for measuring code coverage out of the box. For an example project that uses Jest to measure coverage take a look at Tickety Tick.

There a services that allow you to push coverage information, create project badges and keep a "coverage history" for additional insights. They can be integrated into continuous integration tools and services (e.g. Travis CI). Two popular services are: coveralls.io and codecov.io.