Code Guide

Readability

Always write code with the knowledge that others will be reading it now and in the future:

• Name things accurately and sensibly. errorType makes a hell of a lot more sense than et.
• Don’t be stingy with whitespace. Whitespace is an important factor in readable code. Separate declarations, blocks and conceptually similar chunks of functionality with newlines.

Simplicity

When you write code with a team, simple beats clever, every time. If your clever trick requires an explanatory comment that is longer than the code itself, consider simplifying it so it’s easier to read, understand, and maintain.

Editor preferences

Set your editor to the following settings to avoid common code inconsistencies and dirty diffs:

• Use soft tabs. Preferred spaces-per-tab specified in each language guide.
• Trim trailing white space on save.
• Set encoding to UTF-8.
• Add new line at end of files.

Consider documenting and applying these preferences to your project's .editorconfig file. For an example, see the one in Bootstrap. Learn more about EditorConfig.

Code reviews and linters

The rules in this guide, once agreed upon by your team, can and should be referred to and cited in code reviews.

Also consider setting up code linters in your test suite to enforce these standards, to reduce the pain of instilling good citizenship and keeping the code clean.

• Forked from @mdo’s code guide.
• ES5 standards lifted almost entirely from heavily informed by Douglas Crockford's JavaScript Code Conventions.
• ES6 standards lifted entirely from AirBnB's JavaScript style guide.