1# JavaScript coding standards
2
3Probably the best piece of advice is **to be consistent with the rest of the code in the file**.
4
5We use [ESLint](http://eslint.org/) to analyse JavaScript files automatically, either from within a code editor or from the command line. Here's [our guide to install and configure it](./eslint.md).
6
7For quick reference, here are some of the main code style rules:
8
9* file references to browser globals such as `window` and `document` need `/* eslint-env browser */` at the top of the file,
10* lines should be 90 characters maximum,
11* indent with 2 spaces (no tabs!),
12* `camelCasePlease`,
13* don't open braces on the next line,
14* don't name function expressions: `let o = { doSomething: function doSomething() {} };`,
15* use a space before opening paren for anonymous functions, but don't use one for named functions:
16  * anonymous functions: `function () {}`
17  * named functions: `function foo() {}`
18  * anonymous generators: `function* () {}`
19  * named generators: `function* foo() {}`
20* aim for short functions, 24 lines max (ESLint has a rule that checks for function complexity too),
21* `aArguments aAre the aDevil` (don't use them please),
22* `"use strict";` globally per module,
23* `semicolons; // use them`,
24* no comma-first,
25* consider using Task.jsm (`Task.async`, `Task.spawn`) for nice-looking asynchronous code instead of formatting endless `.then` chains,<!--TODO: shouldn't we advise async/await now?-->
26* use ES6 syntax:
27  * `function setBreakpoint({url, line, column}) { ... }`,
28  * `(...args) => { }` rest args are awesome, no need for `arguments`,
29  * `for..of` loops,
30* don't use non-standard SpiderMonkey-only syntax:
31  * no `for each` loops,
32  * no `function () implicitReturnVal`,
33  * getters / setters require { },
34* only import specific, explicitly-declared symbols into your namespace:
35  * `const { foo, bar } = require("foo/bar");`,
36  * `const { foo, bar } = ChromeUtils.import("...");`,
37* use Maps, Sets, WeakMaps when possible,
38* use [template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals) whenever possible to avoid concatenation, allow multi-line strings, and interpolation.
39
40
41## Comments
42
43Commenting code is important, but bad comments can hurt too, so it's important to have a few rules in mind when commenting:
44
45* If the code can be rewritten to be made more readable, then that should be preferred over writing an explanation as a comment.
46* Instead of writing a comment to explain the meaning of a poorly chosen variable name, then rename that variable.
47* Avoid long separator comments like `// ****************** another section below **********`. They are often a sign that you should split a file in multiple files.
48* Line comments go above the code they are commenting, not at the end of the line.
49* Sentences in comments start with a capital letter and end with a period.
50* Watch out for typos.
51* Obsolete copy/pasted code hurts, make sure you update comments inside copy/pasted code blocks.
52* A global comment at the very top of a file explaining what the file is about and the major types/classes/functions it contains is a good idea for quickly browsing code.
53* If you are forced to employ some kind of hack in your code, and there's no way around it, then add a comment that explains the hack and why it is needed. The reviewer is going to ask for one anyway.
54* Bullet points in comments should use stars aligned with the first comment to format each point
55```javascript
56// headline comment
57// * bullet point 1
58// * bullet point 2
59```
60
61## Asynchronous code
62
63A lot of code in DevTools is asynchronous, because a lot of it relies on connecting to the DevTools server and getting information from there in an asynchronous fashion.
64
65It's easy to make mistakes with asynchronous code, so here are a few guidelines that should help:
66
67* Prefer [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) over callbacks.
68* Use the `new Promise(() => {})` syntax.
69* Don't forget to catch rejections by defining a rejection handler: `promise.then(() => console.log("resolved"), () => console.log("rejected"));` or `promise.catch(() => console.log("rejected"));`.
70* Make use of [`Tasks` and generator functions](https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Task.jsm) to make asynchronous code look synchronous. <!--TODO async/await as in the TODO above?-->
71
72## React & Redux
73
74There are React-specific code style rules in the .eslintrc file.
75
76### Components
77
78* Default to creating components as [stateless function components](https://facebook.github.io/react/docs/reusable-components.html#stateless-functions).
79* If you need local state or lifecycle methods, use `React.createClass` instead of functions.
80* Use React.DOM to create native elements. Assign it to a variable named `dom`, and use it like `dom.div({}, dom.span({}))`. You may also destructure specific elements directly: `const { div, ul } = React.DOM`.
81
82### PropTypes
83
84* Use [PropTypes](https://facebook.github.io/react/docs/reusable-components.html#prop-validation) to define the expected properties of your component. Each directly accessed property (or child of a property) should have a corresponding PropType.
85* Use `isRequired` for any required properties.
86* Place the propTypes definition at the top of the component. If using a stateless function component, place it above the declaration of the function.
87* Where the children property is used, consider [validating the children](http://www.mattzabriskie.com/blog/react-validating-children).
88
89
90