|
151 | 151 | - [10.2](#modules--no-duplicate-imports) Duplicate imports |
152 | 152 | - [10.3](#modules--no-mutable-exports) Mutable exports |
153 | 153 | - [10.4](#modules--imports-first) Imports first |
154 | | - - [10.5](#modules--multiline-imports-over-newlines) Multiline imports |
| 154 | + - [10.5](#modules--import-extensions) Imports extensions |
| 155 | + - [10.6](#modules--multiline-imports-over-newlines) Multiline imports |
155 | 156 |
|
156 | 157 | </details> |
157 | 158 |
|
|
440 | 441 | - `null` |
441 | 442 | - `undefined` |
442 | 443 | - `symbol` |
| 444 | + - `bigint` |
443 | 445 |
|
444 | 446 | ```javascript |
445 | 447 | const foo = 1; |
|
450 | 452 | console.log(foo, bar); // => 1, 9 |
451 | 453 | ``` |
452 | 454 |
|
453 | | - - Symbols cannot be faithfully polyfilled, so they should not be used when targeting browsers/environments that don't support them natively. |
| 455 | + - Symbols and BigInts cannot be faithfully polyfilled, so they should not be used when targeting browsers/environments that don't support them natively. |
454 | 456 |
|
455 | 457 | <a name="types--complex"></a><a name="1.2"></a> |
456 | 458 | - [1.2](#types--complex) **Complex**: When you access a complex type you work on a reference to its value. |
|
880 | 882 | <a name="destructuring--object"></a><a name="5.1"></a> |
881 | 883 | - [5.1](#destructuring--object) Use object destructuring when accessing and using multiple properties of an object. eslint: [`prefer-destructuring`](https://eslint.org/docs/rules/prefer-destructuring) |
882 | 884 |
|
883 | | - > Why? Destructuring saves you from creating temporary references for those properties. |
| 885 | + > Why? Destructuring saves you from creating temporary references for those properties, and from repetitive access of the object. Repeating object access creates more repetitive code, requires more reading, and creates more opportunities for mistakes. Destructuring objects also provides a single site of definition of the object structure that is used in the block, rather than requiring reading the entire block to determine what is used. |
884 | 886 |
|
885 | 887 | ```javascript |
886 | 888 | // bad |
|
1794 | 1796 |
|
1795 | 1797 | foo.init(); |
1796 | 1798 | ``` |
1797 | | - |
1798 | | - <a name="modules--multiline-imports-over-newlines"></a><a name="10.5"></a> |
1799 | | - - [10.5](#modules--multiline-imports-over-newlines) Multiline imports should be indented just like multiline array and object literals. |
| 1799 | + |
| 1800 | + <a name="modules--import-extensions"></a> |
| 1801 | + - [10.5](#modules--import-extensions) Do not include JavaScript filename extensions |
| 1802 | + eslint: [`import/extensions`](https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/extensions.md) |
| 1803 | + > Why? Including extensions inhibits refactoring, and inappropriately hardcodes implementation details of the module you're importing in every consumer. |
| 1804 | + |
| 1805 | + ```javascript |
| 1806 | + // bad |
| 1807 | + import foo from "./foo.js"; |
| 1808 | + import bar from "./bar.jsx"; |
| 1809 | + import baz from "./baz/index.jsx"; |
| 1810 | + |
| 1811 | + // good |
| 1812 | + import foo from "./foo"; |
| 1813 | + import bar from "./bar"; |
| 1814 | + import baz from "./baz"; |
| 1815 | + ``` |
| 1816 | + |
| 1817 | + <a name="modules--multiline-imports-over-newlines"></a><a name="10.6"></a> |
| 1818 | + - [10.6](#modules--multiline-imports-over-newlines) Multiline imports should be indented just like multiline array and object literals. eslint: [`object-curly-newline`](https://eslint.org/docs/rules/object-curly-newline) |
1800 | 1819 |
|
1801 | 1820 | > Why? The curly braces follow the same indentation rules as every other curly brace block in the style guide. |
1802 | 1821 |
|
|
2017 | 2036 | <a name="variables--const-let-group"></a><a name="13.3"></a> |
2018 | 2037 | - [13.3](#variables--const-let-group) Group all your `const`s and then group all your `let`s. |
2019 | 2038 |
|
2020 | | - > Why? This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables. |
| 2039 | + > Why? This is helpful when later on you might need to assign a variable depending on one of the previously assigned variables. |
2021 | 2040 |
|
2022 | 2041 | ```javascript |
2023 | 2042 | // bad |
|
2226 | 2245 | ## Hoisting |
2227 | 2246 |
|
2228 | 2247 | <a name="hoisting--about"></a><a name="14.1"></a> |
2229 | | - - [14.1](#hoisting--about) `var` declarations get hoisted to the top of their closest enclosing function scope, their assignment does not. `const` and `let` declarations are blessed with a new concept called [Temporal Dead Zones (TDZ)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Temporal_dead_zone). It’s important to know why [typeof is no longer safe](http://es-discourse.com/t/why-typeof-is-no-longer-safe/15). |
| 2248 | + - [14.1](#hoisting--about) `var` declarations get hoisted to the top of their closest enclosing function scope, their assignment does not. `const` and `let` declarations are blessed with a new concept called [Temporal Dead Zones (TDZ)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Temporal_dead_zone). It’s important to know why [typeof is no longer safe](https://web.archive.org/web/20200121061528/http://es-discourse.com/t/why-typeof-is-no-longer-safe/15). |
2230 | 2249 |
|
2231 | 2250 | ```javascript |
2232 | 2251 | // this wouldn’t work (assuming there |
|
0 commit comments