diff --git a/README.md b/README.md index f854fed8e7..ba55a75876 100644 --- a/README.md +++ b/README.md @@ -89,9 +89,9 @@ Other Style Guides - [2.1](#2.1) Use `const` for all of your references; avoid using `var`. - > Why? This ensures that you can't reassign your references, which can lead to bugs and difficult to comprehend code. + > Why? This ensures that you can't reassign your references, which can lead to bugs and difficult to comprehend code. - eslint rules: [`prefer-const`](http://eslint.org/docs/rules/prefer-const.html), [`no-const-assign`](http://eslint.org/docs/rules/no-const-assign.html). + eslint rules: [`prefer-const`](http://eslint.org/docs/rules/prefer-const.html), [`no-const-assign`](http://eslint.org/docs/rules/no-const-assign.html). ```javascript // bad @@ -105,9 +105,9 @@ Other Style Guides - [2.2](#2.2) If you must reassign references, use `let` instead of `var`. - > Why? `let` is block-scoped rather than function-scoped like `var`. + > Why? `let` is block-scoped rather than function-scoped like `var`. - eslint rules: [`no-var`](http://eslint.org/docs/rules/no-var.html). + eslint rules: [`no-var`](http://eslint.org/docs/rules/no-var.html). ```javascript // bad @@ -141,7 +141,7 @@ Other Style Guides - [3.1](#3.1) Use the literal syntax for object creation. - eslint rules: [`no-new-object`](http://eslint.org/docs/rules/no-new-object.html). + eslint rules: [`no-new-object`](http://eslint.org/docs/rules/no-new-object.html). ```javascript // bad @@ -187,14 +187,14 @@ Other Style Guides ``` + - [3.4](#3.4) Use computed property names when creating objects with dynamic property names. - > Why? They allow you to define all the properties of an object in one place. + > Why? They allow you to define all the properties of an object in one place. ```javascript - function getKey(k) { - return `a key named ${k}`; + return 'a key named ${k}'; } // bad @@ -213,9 +213,10 @@ Other Style Guides ``` + - [3.5](#3.5) Use object method shorthand. - eslint rules: [`object-shorthand`](http://eslint.org/docs/rules/object-shorthand.html). + eslint rules: [`object-shorthand`](http://eslint.org/docs/rules/object-shorthand.html). ```javascript // bad @@ -238,11 +239,12 @@ Other Style Guides ``` + - [3.6](#3.6) Use property value shorthand. - > Why? It is shorter to write and descriptive. + > Why? It is shorter to write and descriptive. - eslint rules: [`object-shorthand`](http://eslint.org/docs/rules/object-shorthand.html). + eslint rules: [`object-shorthand`](http://eslint.org/docs/rules/object-shorthand.html). ```javascript const lukeSkywalker = 'Luke Skywalker'; @@ -260,7 +262,7 @@ Other Style Guides - [3.7](#3.7) Group your shorthand properties at the beginning of your object declaration. - > Why? It's easier to tell which properties are using the shorthand. + > Why? It's easier to tell which properties are using the shorthand. ```javascript const anakinSkywalker = 'Anakin Skywalker'; @@ -293,7 +295,7 @@ Other Style Guides - [4.1](#4.1) Use the literal syntax for array creation. - eslint rules: [`no-array-constructor`](http://eslint.org/docs/rules/no-array-constructor.html). + eslint rules: [`no-array-constructor`](http://eslint.org/docs/rules/no-array-constructor.html). ```javascript // bad @@ -316,6 +318,7 @@ Other Style Guides ``` + - [4.3](#4.3) Use array spreads `...` to copy arrays. ```javascript @@ -344,7 +347,7 @@ Other Style Guides - [5.1](#5.1) Use object destructuring when accessing and using multiple properties of an object. - > Why? Destructuring saves you from creating temporary references for those properties. + > Why? Destructuring saves you from creating temporary references for those properties. ```javascript // bad @@ -382,7 +385,7 @@ Other Style Guides - [5.3](#5.3) Use object destructuring for multiple return values, not array destructuring. - > Why? You can add new properties over time or change the order of things without breaking call sites. + > Why? You can add new properties over time or change the order of things without breaking call sites. ```javascript // bad @@ -411,7 +414,7 @@ Other Style Guides - [6.1](#6.1) Use single quotes `''` for strings. - eslint rules: [`quotes`](http://eslint.org/docs/rules/quotes.html). + eslint rules: [`quotes`](http://eslint.org/docs/rules/quotes.html). ```javascript // bad @@ -441,11 +444,12 @@ Other Style Guides ``` + - [6.4](#6.4) When programmatically building up strings, use template strings instead of concatenation. - > Why? Template strings give you a readable, concise syntax with proper newlines and string interpolation features. + > Why? Template strings give you a readable, concise syntax with proper newlines and string interpolation features. - eslint rules: [`prefer-template`](http://eslint.org/docs/rules/prefer-template.html). + eslint rules: [`prefer-template`](http://eslint.org/docs/rules/prefer-template.html). ```javascript // bad @@ -472,7 +476,7 @@ Other Style Guides - [7.1](#7.1) Use function declarations instead of function expressions. - > Why? Function declarations are named, so they're easier to identify in call stacks. Also, the whole body of a function declaration is hoisted, whereas only the reference of a function expression is hoisted. This rule makes it possible to always use [Arrow Functions](#arrow-functions) in place of function expressions. + > Why? Function declarations are named, so they're easier to identify in call stacks. Also, the whole body of a function declaration is hoisted, whereas only the reference of a function expression is hoisted. This rule makes it possible to always use [Arrow Functions](#arrow-functions) in place of function expressions. ```javascript // bad @@ -528,9 +532,10 @@ Other Style Guides ``` + - [7.6](#7.6) Never use `arguments`, opt to use rest syntax `...` instead. - > Why? `...` is explicit about which arguments you want pulled. Plus rest arguments are a real Array and not Array-like like `arguments`. + > Why? `...` is explicit about which arguments you want pulled. Plus rest arguments are a real Array and not Array-like like `arguments`. ```javascript // bad @@ -546,6 +551,7 @@ Other Style Guides ``` + - [7.7](#7.7) Use default parameter syntax rather than mutating function arguments. ```javascript @@ -574,19 +580,19 @@ Other Style Guides - [7.8](#7.8) Avoid side effects with default parameters. - > Why? They are confusing to reason about. + > Why? They are confusing to reason about. - ```javascript - var b = 1; - // bad - function count(a = b++) { - console.log(a); - } - count(); // 1 - count(); // 2 - count(3); // 3 - count(); // 3 - ``` + ```javascript + var b = 1; + // bad + function count(a = b++) { + console.log(a); + } + count(); // 1 + count(); // 2 + count(3); // 3 + count(); // 3 + ``` - [7.9](#7.9) Always put default parameters last. @@ -602,32 +608,32 @@ Other Style Guides } ``` -- [7.10](#7.10) Never use the Function constructor to create a new function. + - [7.10](#7.10) Never use the Function constructor to create a new function. - > Why? Creating a function in this way evaluates a string similarly to eval(), which opens vulnerabilities. + > Why? Creating a function in this way evaluates a string similarly to eval(), which opens vulnerabilities. - ```javascript - // bad - var add = new Function('a', 'b', 'return a + b'); + ```javascript + // bad + var add = new Function('a', 'b', 'return a + b'); - // still bad - var subtract = Function('a', 'b', 'return a - b'); - ``` + // still bad + var subtract = Function('a', 'b', 'return a - b'); + ``` -- [7.11](#7.11) Spacing in a function signature. + - [7.11](#7.11) Spacing in a function signature. - > Why? Consistency is good, and you shouldn’t have to add or remove a space when adding or removing a name. + > Why? Consistency is good, and you shouldn’t have to add or remove a space when adding or removing a name. - ```javascript - // bad - const f = function(){}; - const g = function (){}; - const h = function() {}; + ```javascript + // bad + const f = function(){}; + const g = function (){}; + const h = function() {}; - // good - const x = function () {}; - const y = function a() {}; - ``` + // good + const x = function () {}; + const y = function a() {}; + ``` **[⬆ back to top](#table-of-contents)** @@ -635,11 +641,11 @@ Other Style Guides - [8.1](#8.1) When you must use function expressions (as when passing an anonymous function), use arrow function notation. - > Why? It creates a version of the function that executes in the context of `this`, which is usually what you want, and is a more concise syntax. + > Why? It creates a version of the function that executes in the context of `this`, which is usually what you want, and is a more concise syntax. - > Why not? If you have a fairly complicated function, you might move that logic out into its own function declaration. + > Why not? If you have a fairly complicated function, you might move that logic out into its own function declaration. - eslint rules: [`prefer-arrow-callback`](http://eslint.org/docs/rules/prefer-arrow-callback.html), [`arrow-spacing`](http://eslint.org/docs/rules/arrow-spacing.html). + eslint rules: [`prefer-arrow-callback`](http://eslint.org/docs/rules/prefer-arrow-callback.html), [`arrow-spacing`](http://eslint.org/docs/rules/arrow-spacing.html). ```javascript // bad @@ -657,34 +663,34 @@ Other Style Guides - [8.2](#8.2) If the function body consists of a single expression, feel free to omit the braces and use the implicit return. Otherwise use a `return` statement. - > Why? Syntactic sugar. It reads well when multiple functions are chained together. + > Why? Syntactic sugar. It reads well when multiple functions are chained together. - > Why not? If you plan on returning an object. + > Why not? If you plan on returning an object. - eslint rules: [`arrow-parens`](http://eslint.org/docs/rules/arrow-parens.html), [`arrow-body-style`](http://eslint.org/docs/rules/arrow-body-style.html). + eslint rules: [`arrow-parens`](http://eslint.org/docs/rules/arrow-parens.html), [`arrow-body-style`](http://eslint.org/docs/rules/arrow-body-style.html). ```javascript // good - [1, 2, 3].map(number => `A string containing the ${number}.`); + [1, 2, 3].map(number => 'A string containing the ${number}.'); // bad [1, 2, 3].map(number => { const nextNumber = number + 1; - `A string containing the ${nextNumber}.`; + 'A string containing the ${nextNumber}.'; }); // good [1, 2, 3].map(number => { const nextNumber = number + 1; - return `A string containing the ${nextNumber}.`; + return 'A string containing the ${nextNumber}.'; }); ``` - [8.3](#8.3) In case the expression spans over multiple lines, wrap it in parentheses for better readability. - > Why? It shows clearly where the function starts and ends. + > Why? It shows clearly where the function starts and ends. - ```js + ```javascript // bad [1, 2, 3].map(number => 'As time went by, the string containing the ' + `${number} became much longer. So we needed to break it over multiple ` + @@ -701,11 +707,11 @@ Other Style Guides - [8.4](#8.4) If your function only takes a single argument, feel free to omit the parentheses. - > Why? Less visual clutter. + > Why? Less visual clutter. - eslint rules: [`arrow-parens`](http://eslint.org/docs/rules/arrow-parens.html). + eslint rules: [`arrow-parens`](http://eslint.org/docs/rules/arrow-parens.html). - ```js + ```javascript // good [1, 2, 3].map(x => x * x); @@ -720,7 +726,7 @@ Other Style Guides - [9.1](#9.1) Always use `class`. Avoid manipulating `prototype` directly. - > Why? `class` syntax is more concise and easier to reason about. + > Why? `class` syntax is more concise and easier to reason about. ```javascript // bad @@ -749,7 +755,7 @@ Other Style Guides - [9.2](#9.2) Use `extends` for inheritance. - > Why? It is a built-in way to inherit prototype functionality without breaking `instanceof`. + > Why? It is a built-in way to inherit prototype functionality without breaking `instanceof`. ```javascript // bad @@ -832,7 +838,7 @@ Other Style Guides - [10.1](#10.1) Always use modules (`import`/`export`) over a non-standard module system. You can always transpile to your preferred module system. - > Why? Modules are the future, let's start using the future now. + > Why? Modules are the future, let's start using the future now. ```javascript // bad @@ -850,7 +856,7 @@ Other Style Guides - [10.2](#10.2) Do not use wildcard imports. - > Why? This makes sure you have a single default export. + > Why? This makes sure you have a single default export. ```javascript // bad @@ -862,7 +868,7 @@ Other Style Guides - [10.3](#10.3) And do not export directly from an import. - > Why? Although the one-liner is concise, having one clear way to import and one clear way to export makes things consistent. + > Why? Although the one-liner is concise, having one clear way to import and one clear way to export makes things consistent. ```javascript // bad @@ -881,9 +887,9 @@ Other Style Guides - [11.1](#11.1) Don't use iterators. Prefer JavaScript's higher-order functions like `map()` and `reduce()` instead of loops like `for-of`. - > Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side-effects. + > Why? This enforces our immutable rule. Dealing with pure functions that return values is easier to reason about than side-effects. - eslint rules: [`no-iterator`](http://eslint.org/docs/rules/no-iterator.html). + eslint rules: [`no-iterator`](http://eslint.org/docs/rules/no-iterator.html). ```javascript const numbers = [1, 2, 3, 4, 5]; @@ -917,7 +923,7 @@ Other Style Guides - [12.1](#12.1) Use dot notation when accessing properties. - eslint rules: [`dot-notation`](http://eslint.org/docs/rules/dot-notation.html). + eslint rules: [`dot-notation`](http://eslint.org/docs/rules/dot-notation.html). ```javascript const luke = { @@ -966,7 +972,7 @@ Other Style Guides > Why? It's easier to add new variable declarations this way, and you never have to worry about swapping out a `;` for a `,` or introducing punctuation-only diffs. - eslint rules: [`one-var`](http://eslint.org/docs/rules/one-var.html). + eslint rules: [`one-var`](http://eslint.org/docs/rules/one-var.html). ```javascript // bad @@ -988,7 +994,7 @@ Other Style Guides - [13.3](#13.3) Group all your `const`s and then group all your `let`s. - > Why? This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables. + > Why? This is helpful when later on you might need to assign a variable depending on one of the previous assigned variables. ```javascript // bad @@ -1013,7 +1019,7 @@ Other Style Guides - [13.4](#13.4) Assign variables where you need them, but place them in a reasonable place. - > Why? `let` and `const` are block scoped and not function scoped. + > Why? `let` and `const` are block scoped and not function scoped. ```javascript // good @@ -1162,7 +1168,7 @@ Other Style Guides - [15.1](#15.1) Use `===` and `!==` over `==` and `!=`. - [15.2](#15.2) Conditional statements such as the `if` statement evaluate their expression using coercion with the `ToBoolean` abstract method and always follow these simple rules: - eslint rules: [`eqeqeq`](http://eslint.org/docs/rules/eqeqeq.html). + eslint rules: [`eqeqeq`](http://eslint.org/docs/rules/eqeqeq.html). + **Objects** evaluate to **true** + **Undefined** evaluates to **false** @@ -1368,7 +1374,7 @@ Other Style Guides - [18.1](#18.1) Use soft tabs set to 2 spaces. - eslint rules: [`indent`](http://eslint.org/docs/rules/indent.html). + eslint rules: [`indent`](http://eslint.org/docs/rules/indent.html). ```javascript // bad @@ -1389,7 +1395,7 @@ Other Style Guides - [18.2](#18.2) Place 1 space before the leading brace. - eslint rules: [`space-before-blocks`](http://eslint.org/docs/rules/space-before-blocks.html). + eslint rules: [`space-before-blocks`](http://eslint.org/docs/rules/space-before-blocks.html). ```javascript // bad @@ -1417,7 +1423,7 @@ Other Style Guides - [18.3](#18.3) Place 1 space before the opening parenthesis in control statements (`if`, `while` etc.). Place no space before the argument list in function calls and declarations. - eslint rules: [`space-after-keywords`](http://eslint.org/docs/rules/space-after-keywords.html), [`space-before-keywords`](http://eslint.org/docs/rules/space-before-keywords.html). + eslint rules: [`space-after-keywords`](http://eslint.org/docs/rules/space-after-keywords.html), [`space-before-keywords`](http://eslint.org/docs/rules/space-before-keywords.html). ```javascript // bad @@ -1443,7 +1449,7 @@ Other Style Guides - [18.4](#18.4) Set off operators with spaces. - eslint rules: [`space-infix-ops`](http://eslint.org/docs/rules/space-infix-ops.html). + eslint rules: [`space-infix-ops`](http://eslint.org/docs/rules/space-infix-ops.html). ```javascript // bad @@ -1576,7 +1582,7 @@ Other Style Guides - [18.8](#18.8) Do not pad your blocks with blank lines. - eslint rules: [`padded-blocks`](http://eslint.org/docs/rules/padded-blocks.html). + eslint rules: [`padded-blocks`](http://eslint.org/docs/rules/padded-blocks.html). ```javascript // bad @@ -1610,7 +1616,7 @@ Other Style Guides - [18.9](#18.9) Do not add spaces inside parentheses. - eslint rules: [`space-in-parens`](http://eslint.org/docs/rules/space-in-parens.html). + eslint rules: [`space-in-parens`](http://eslint.org/docs/rules/space-in-parens.html). ```javascript // bad @@ -1636,7 +1642,7 @@ Other Style Guides - [18.10](#18.10) Do not add spaces inside brackets. - eslint rules: [`array-bracket-spacing`](http://eslint.org/docs/rules/array-bracket-spacing.html). + eslint rules: [`array-bracket-spacing`](http://eslint.org/docs/rules/array-bracket-spacing.html). ```javascript // bad @@ -1650,7 +1656,7 @@ Other Style Guides - [18.11](#18.11) Add spaces inside curly braces. - eslint rules: [`object-curly-spacing`](http://eslint.org/docs/rules/object-curly-spacing.html). + eslint rules: [`object-curly-spacing`](http://eslint.org/docs/rules/object-curly-spacing.html). ```javascript // bad @@ -1666,7 +1672,7 @@ Other Style Guides - [19.1](#19.1) Leading commas: **Nope.** - eslint rules: [`comma-style`](http://eslint.org/docs/rules/comma-style.html). + eslint rules: [`comma-style`](http://eslint.org/docs/rules/comma-style.html). ```javascript // bad @@ -1702,9 +1708,9 @@ Other Style Guides - [19.2](#19.2) Additional trailing comma: **Yup.** - eslint rules: [`no-comma-dangle`](http://eslint.org/docs/rules/no-comma-dangle.html). + eslint rules: [`no-comma-dangle`](http://eslint.org/docs/rules/no-comma-dangle.html). - > Why? This leads to cleaner git diffs. Also, transpilers like Babel will remove the additional trailing comma in the transpiled code which means you don't have to worry about the [trailing comma problem](es5/README.md#commas) in legacy browsers. + > Why? This leads to cleaner git diffs. Also, transpilers like Babel will remove the additional trailing comma in the transpiled code which means you don't have to worry about the [trailing comma problem](es5/README.md#commas) in legacy browsers. ```javascript // bad - git diff without trailing comma @@ -1752,7 +1758,7 @@ Other Style Guides - [20.1](#20.1) **Yup.** - eslint rules: [`semi`](http://eslint.org/docs/rules/semi.html). + eslint rules: [`semi`](http://eslint.org/docs/rules/semi.html). ```javascript // bad @@ -1874,7 +1880,7 @@ Other Style Guides - [22.2](#22.2) Use camelCase when naming objects, functions, and instances. - eslint rules: [`camelcase`](http://eslint.org/docs/rules/camelcase.html). + eslint rules: [`camelcase`](http://eslint.org/docs/rules/camelcase.html). ```javascript // bad @@ -1913,7 +1919,7 @@ Other Style Guides - [22.4](#22.4) Use a leading underscore `_` when naming private properties. - eslint rules: [`no-underscore-dangle`](http://eslint.org/docs/rules/no-underscore-dangle.html). + eslint rules: [`no-underscore-dangle`](http://eslint.org/docs/rules/no-underscore-dangle.html). ```javascript // bad diff --git a/react/README.md b/react/README.md index 6b0a8e13e9..2b4329cfad 100644 --- a/react/README.md +++ b/react/README.md @@ -111,7 +111,7 @@ superLongParam="bar" anotherSuperLongParam="baz" > - + ```