Permalink
Browse files

Docs: Distinguish examples in rules under Best Practices part 2

  • Loading branch information...
pedrottimark committed Mar 7, 2016
1 parent dd390c7 commit 4f06f2f53ddf908cc7a9a1542c68dd0e1cd8e7cc
@@ -22,10 +22,11 @@ list.map(() => ({})); // This is an empty object.
This rule is aimed at eliminating empty functions.
A function will not be considered a problem if it contains a comment.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-empty-function: "error"*/
/*eslint-env es6*/
function foo() {}
@@ -72,10 +73,11 @@ class A {
}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-empty-function: "error"*/
/*eslint-env es6*/
function foo() {
// do nothing.
@@ -164,13 +166,7 @@ class A {
## Options
```json
{
"no-empty-function": ["error", {"allow": []}]
}
```
This rule has an option to allow empty of specific kind's functions.
This rule has an option to allow specific kinds of functions to be empty.
* `allow` (`string[]`) - A list of kind to allow empty functions. List items are some of the following strings. An empty array (`[]`) by default.
* `"functions"` - Normal functions.
@@ -182,10 +178,12 @@ This rule has an option to allow empty of specific kind's functions.
* `"setters"` - Setters.
* `"constructors"` - Class constructors.
The following patterns are not considered problems when configured with `{"allow": ["functions"]}`:
#### allow: functions
Examples of **correct** code for the `{ "allow": ["functions"] }` option:
```js
/*eslint no-empty-function: ["error", {"allow": ["functions"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["functions"] }]*/
function foo() {}
@@ -196,18 +194,24 @@ var obj = {
};
```
The following patterns are not considered problems when configured with `{"allow": ["arrowFunctions"]}`:
#### allow: arrowFunctions
Examples of **correct** code for the `{ "allow": ["arrowFunctions"] }` option:
```js
/*eslint no-empty-function: ["error", {"allow": ["arrowFunctions"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["arrowFunctions"] }]*/
/*eslint-env es6*/
var foo = () => {};
```
The following patterns are not considered problems when configured with `{"allow": ["generatorFunctions"]}`:
#### allow: generatorFunctions
Examples of **correct** code for the `{ "allow": ["generatorFunctions"] }` option:
```js
/*eslint no-empty-function: ["error", {"allow": ["generatorFunctions"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["generatorFunctions"] }]*/
/*eslint-env es6*/
function* foo() {}
@@ -218,10 +222,13 @@ var obj = {
};
```
The following patterns are not considered problems when configured with `{"allow": ["methods"]}`:
#### allow: methods
Examples of **correct** code for the `{ "allow": ["methods"] }` option:
```js
/*eslint no-empty-function: [2, {"allow": ["methods"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["methods"] }]*/
/*eslint-env es6*/
var obj = {
foo() {}
@@ -233,10 +240,13 @@ class A {
}
```
The following patterns are not considered problems when configured with `{"allow": ["generatorMethods"]}`:
#### allow: generatorMethods
Examples of **correct** code for the `{ "allow": ["generatorMethods"] }` option:
```js
/*eslint no-empty-function: [2, {"allow": ["generatorMethods"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["generatorMethods"] }]*/
/*eslint-env es6*/
var obj = {
*foo() {}
@@ -248,10 +258,13 @@ class A {
}
```
The following patterns are not considered problems when configured with `{"allow": ["getters"]}`:
#### allow: getters
Examples of **correct** code for the `{ "allow": ["getters"] }` option:
```js
/*eslint no-empty-function: [2, {"allow": ["getters"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["getters"] }]*/
/*eslint-env es6*/
var obj = {
get foo() {}
@@ -263,10 +276,13 @@ class A {
}
```
The following patterns are not considered problems when configured with `{"allow": ["setters"]}`:
#### allow: setters
Examples of **correct** code for the `{ "allow": ["setters"] }` option:
```js
/*eslint no-empty-function: [2, {"allow": ["setters"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["setters"] }]*/
/*eslint-env es6*/
var obj = {
set foo(value) {}
@@ -278,10 +294,13 @@ class A {
}
```
The following patterns are not considered problems when configured with `{"allow": ["constructors"]}`:
#### allow: constructors
Examples of **correct** code for the `{ "allow": ["constructors"] }` option:
```js
/*eslint no-empty-function: [2, {"allow": ["constructors"]}]*/
/*eslint no-empty-function: ["error", { "allow": ["constructors"] }]*/
/*eslint-env es6*/
class A {
constructor() {}
@@ -2,21 +2,21 @@
When using destructuring, it's possible to create a pattern that has no effect. This happens when empty curly braces are used to the right of an embedded object destructuring pattern, such as:
```
```js
// doesn't create any variables
var {a: {}} = foo;
```
In this code, no new variables are created because `a` is just a location helper while the `{}` is expected to contain the variables to create, such as:
```
```js
// creates variable b
var {a: { b }} = foo;
```
In many cases, the empty object pattern is a mistake where the author intended to use a default value instead, such as:
```
```js
// creates variable a
var {a = {}} = foo;
```
@@ -27,7 +27,7 @@ The difference between these two patterns is subtle, especially because the prob
This rule aims to flag any empty patterns in destructured objects and arrays, and as such, will report a problem whenever one is encountered.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-empty-pattern: "error"*/
@@ -42,7 +42,7 @@ function foo({a: {}}) {}
function foo({a: []}) {}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-empty-pattern: "error"*/
View
@@ -12,7 +12,7 @@ if (foo == null) {
The `no-eq-null` rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to `null` only match `null`, and not also `undefined`. As such it will flag comparisons to null when using `==` and `!=`.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-eq-null: "error"*/
@@ -26,7 +26,7 @@ while (qux != null) {
}
```
The following patterns are considered okay:
Examples of **correct** code for this rule:
```js
/*eslint no-eq-null: "error"*/
View
@@ -12,7 +12,7 @@ var obj = { x: "foo" },
This rule is aimed at preventing potentially dangerous, unnecessary, and slow code by disallowing the use of the `eval()` function. As such, it will warn whenever the `eval()` function is used.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-eval: "error"*/
@@ -44,10 +44,11 @@ window.eval("var a = 0");
global.eval("var a = 0");
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-eval: "error"*/
/*eslint-env es6*/
var obj = { x: "foo" },
key = "x",
@@ -24,28 +24,46 @@ A common suggestion to avoid this problem would be to wrap the inside of the `fo
## Rule Details
Disallows directly modifying the prototype of builtin objects by looking for the following styles:
Disallows directly modifying the prototype of builtin objects.
* `Object.prototype.a = "a";`
* `Object.defineProperty(Array.prototype, "times", {value: 999});`
Examples of **incorrect** code for this rule:
It *does not* check for any of the following less obvious approaches:
```js
/*eslint no-extend-native: 2*/
* `var x = Object; x.prototype.thing = a;`
* `eval("Array.prototype.forEach = 'muhahaha'");`
* `with(Array) { prototype.thing = 'thing'; };`
* `window.Function.prototype.bind = 'tight';`
Object.prototype.a = "a";
Object.defineProperty(Array.prototype, "times", { value: 999 });
```
## Options
This rule accepts an `exceptions` option, which can be used to specify a list of builtins for which extensions will be allowed:
This rule accepts an `exceptions` option, which can be used to specify a list of builtins for which extensions will be allowed.
```json
{
"rules": {
"no-extend-native": ["error", {"exceptions": ["Object"]}]
}
}
### exceptions
Examples of **correct** code for the sample `{ "exceptions": ["Object"] }` option:
```js
/*eslint no-extend-native: ["error", { "exceptions": ["Object"] }]*/
Object.prototype.a = "a";
```
## Known Limitations
This rule *does not* report any of the following less obvious approaches to modify the prototype of builtin objects:
```js
var x = Object;
x.prototype.thing = a;
eval("Array.prototype.forEach = 'muhahaha'");
with(Array) {
prototype.thing = 'thing';
};
window.Function.prototype.bind = 'tight';
```
## When Not To Use It
@@ -31,7 +31,7 @@ This rule is aimed at avoiding the unnecessary use of `bind()` and as such will
**Note:** Arrow functions can never have their `this` value set using `bind()`. This rule flags all uses of `bind()` with arrow functions as a problem
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-extra-bind: "error"*/
@@ -62,7 +62,7 @@ var x = function () {
}.bind(baz);
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-extra-bind: "error"*/
@@ -15,7 +15,7 @@ Probably those labels would confuse developers because they expect labels to jum
This rule is aimed at eliminating unnecessary labels.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-extra-label: "error"*/
@@ -34,7 +34,7 @@ C: switch (a) {
}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-extra-label: "error"*/
@@ -25,7 +25,7 @@ switch(foo) {
}
```
That works fine when you don't want a fallthrough, but what if the fallthrough is intentional, there is no way to indicate that in the language. It's considered a best practice to always indicate when a fallthrough is intentional using a comment:
That works fine when you don't want a fallthrough, but what if the fallthrough is intentional, there is no way to indicate that in the language. It's considered a best practice to always indicate when a fallthrough is intentional using a comment which matches the `/falls?\s?through/i` regular expression:
```js
switch(foo) {
@@ -62,7 +62,7 @@ In this example, there is no confusion as to the expected behavior. It is clear
This rule is aimed at eliminating unintentional fallthrough of one case to the other. As such, it flags and fallthrough scenarios that are not marked by a comment.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-fallthrough: "error"*/
@@ -76,7 +76,7 @@ switch(foo) {
}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-fallthrough: "error"*/
@@ -14,7 +14,7 @@ Although not a syntax error, this format for numbers can make it difficult to di
This rule is aimed at eliminating floating decimal points and will warn whenever a numeric value has a decimal point but is missing a number either before or after it.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-floating-decimal: "error"*/
@@ -24,13 +24,14 @@ var num = 2.;
var num = -.7;
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-floating-decimal: "error"*/
var num = 0.5;
var num = 2.0;
var num = -0.7;
```
## When Not To Use It
Oops, something went wrong.

0 comments on commit 4f06f2f

Please sign in to comment.