Permalink
Browse files

Docs: Distinguish examples in rules under Variables

  • Loading branch information...
pedrottimark committed Feb 22, 2016
1 parent bd67a61 commit 119e0eda1fe9a281dcf6cce810d4e52e73d6f120
@@ -59,7 +59,9 @@ Variables must not be initialized at declaration, except in for loops, where it
}
```
When configured with `"always"` (the default), the following patterns are considered problems:
### always
Examples of **incorrect** code for the default `"always"` option:
```js
/*eslint init-declarations: [2, "always"]*/
@@ -71,7 +73,7 @@ function foo() {
}
```
The following patterns are not considered problems with `"always"`.
Examples of **correct** code for the default `"always"` option:
```js
/*eslint init-declarations: [2, "always"]*/
@@ -84,7 +86,9 @@ function foo() {
}
```
When configured with `"never"`, the following patterns are considered problems.
### never
Examples of **incorrect** code for the `"never"` option:
```js
/*eslint init-declarations: [2, "never"]*/
@@ -98,7 +102,7 @@ function foo() {
}
```
The following patterns are not considered problems with `"never"`. Note that `const` variable initializations are ignored with `"never"`.
Examples of **correct** code for the `"never"` option:
```js
/*eslint init-declarations: [2, "never"]*/
@@ -111,7 +115,11 @@ function foo() {
}
```
With `"ignoreForLoopInit"` enabled, the following pattern is not considered a problem.
The `"never"` option ignores `const` variable initializations.
### ignoreForLoopInit
Examples of **correct** code for the `"never", { "ignoreForLoopInit": true }` options:
```js
/*eslint init-declarations: [2, "never", { "ignoreForLoopInit": true }]*/
@@ -18,7 +18,7 @@ console.log(err) // err is 'problem', not 'x'
This rule is aimed at preventing unexpected behavior in your program that may arise from a bug in IE 8 and earlier, in which the catch clause parameter can leak into outer scopes. This rule will warn whenever it encounters a catch clause parameter that has the same name as a variable in an outer scope.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-catch-shadow: 2*/
@@ -42,9 +42,11 @@ try {
}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-catch-shadow: 2*/
var err = "x";
try {
@@ -1,6 +1,12 @@
# Disallow Variables Deletion (no-delete-var)
This rule prevents the use of `delete` operator on variables:
The purpose of the `delete` operator is to remove a property from an object. Using the `delete` operator on a variable might lead to unexpected behavior.
## Rule Details
This rule prevents the use of `delete` operator on variables.
Examples of **incorrect** code for this rule:
```js
/*eslint no-delete-var: 2*/
@@ -9,8 +15,6 @@ var x;
delete x;
```
The delete operator will only delete the properties of objects. It cannot "delete" variables or anything else. Using them on variables might lead to unexpected behavior.
## Further Reading
* [Only properties should be deleted](http://jslinterrors.com/only-properties-should-be-deleted/)
@@ -4,7 +4,7 @@
This rule aims to create clearer code by disallowing the bad practice of creating a label that shares a name with a variable that is in scope.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-label-var: 2*/
@@ -18,7 +18,7 @@ x:
}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-label-var: 2*/
@@ -10,7 +10,7 @@ Then any code used within the same scope would not get the global `undefined`, b
## Rule Details
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-shadow-restricted-names: 2*/
@@ -24,7 +24,7 @@ var undefined;
try {} catch(eval){}
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-shadow-restricted-names: 2*/
@@ -38,3 +38,7 @@ function f(a, b){}
* [Annotated ES5 - §15.1.1](http://es5.github.io/#x15.1.1)
* [Annotated ES5 - Annex C](http://es5.github.io/#C)
## Related Rules
* [no-shadow](no-shadow.md)
View
@@ -15,7 +15,7 @@ In this case, the variable `a` inside of `b()` is shadowing the variable `a` in
This rule aims to eliminate shadowed variable declarations.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-shadow: 2*/
@@ -46,16 +46,16 @@ This rule takes one option, an object, with properties `"builtinGlobals"`, `"hoi
```json
{
"no-shadow": [2, {"builtinGlobals": false, "hoist": "functions", "allow": []}]
"no-shadow": [2, { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}
```
### `builtinGlobals`
### builtinGlobals
`false` by default.
If this is `true`, this rule checks with built-in global variables such as `Object`, `Array`, `Number`, ...
The `builtinGlobals` option is `false` by default.
If it is `true`, the rule prevents shadowing of built-in global variables: `Object`, `Array`, `Number`, and so on.
When `{"builtinGlobals": true}`, the following patterns are considered problems:
Examples of **incorrect** code for the `{ "builtinGlobals": true }` option:
```js
/*eslint no-shadow: [2, { "builtinGlobals": true }]*/
@@ -65,39 +65,54 @@ function foo() {
}
```
### `hoist`
### hoist
The option has three settings:
The `hoist` option has three settings:
* `all` - reports all shadowing before the outer variables/functions are defined.
* `functions` (by default) - reports shadowing before the outer functions are defined.
* `all` - reports all shadowing before the outer variables/functions are defined.
* `never` - never report shadowing before the outer variables/functions are defined.
#### `{ "hoist": "all" }`
#### hoist: functions
With `"hoist"` set to `"all"`, both `let a` and `let b` in the `if` statement are considered problems.
Examples of **incorrect** code for the default `{ "hoist": "functions" }` option:
```js
/*eslint no-shadow: [2, { "hoist": "all" }]*/
/*eslint no-shadow: [2, { "hoist": "functions" }]*/
/*eslint-env es6*/
if (true) {
let a = 3;
let b = 6;
}
let a = 5;
function b() {}
```
#### `{ "hoist": "functions" }` (default)
Although `let b` in the `if` statement is before the *function* declaration in the outer scope, it is incorrect.
With `"hoist"` set to `"functions"`, `let b` is considered a warning. But `let a` in the `if` statement is not considered a warning, because it is before `let a` of the outer scope.
Examples of **correct** code for the default `{ "hoist": "functions" }` option:
```js
/*eslint no-shadow: [2, { "hoist": "functions" }]*/
/*eslint-env es6*/
if (true) {
let a = 3;
}
let a = 5;
```
Because `let a` in the `if` statement is before the *variable* declaration in the outer scope, it is correct.
#### hoist: all
Examples of **incorrect** code for the `{ "hoist": "all" }` option:
```js
/*eslint no-shadow: [2, { "hoist": "all" }]*/
/*eslint-env es6*/
if (true) {
let a = 3;
let b = 6;
@@ -107,9 +122,9 @@ let a = 5;
function b() {}
```
#### `{ "hoist": "never" }`
#### hoist: never
With `"hoist"` set to `"never"`, neither `let a` nor `let b` in the `if` statement are considered problems, because they are before the declarations of the outer scope.
Examples of **correct** code for the `{ "hoist": "never" }` option:
```js
/*eslint no-shadow: [2, { "hoist": "never" }]*/
@@ -124,21 +139,18 @@ let a = 5;
function b() {}
```
### `allow`
Because `let a` and `let b` in the `if` statement are before the declarations in the outer scope, they are correct.
The option is an array of identifier names to be allowed (ie. "resolve", "reject", "done", "cb" etc.):
### allow
```json
{
"rules": {
"no-shadow": [2, {"allow": ["done"]}]
}
}
```
The `allow` option is an array of identifier names for which shadowing is allowed. For example, `"resolve"`, `"reject"`, `"done"`, `"cb"`.
Allows for the following code to be valid:
Examples of **correct** code for the `{ "allow": ["done"] }` option:
```js
/*eslint no-shadow: [2, { "allow": ["done"] }]*/
/*eslint-env es6*/
import async from 'async';
function foo(done) {
@@ -155,3 +167,7 @@ foo(function (err, result) {
## Further Reading
* [Variable Shadowing](http://en.wikipedia.org/wiki/Variable_shadowing)
## Related Rules
* [no-shadow-restricted-names](no-shadow-restricted-names.md)
@@ -21,7 +21,7 @@ It's considered a best practice to avoid initializing variables to `undefined`.
This rule aims to eliminate variable declarations that initialize to `undefined`.
The following patterns are considered problems:
Examples of **incorrect** code for this rule:
```js
/*eslint no-undef-init: 2*/
@@ -31,7 +31,7 @@ var foo = undefined;
let bar = undefined;
```
The following patterns are not considered problems:
Examples of **correct** code for this rule:
```js
/*eslint no-undef-init: 2*/
Oops, something went wrong.

0 comments on commit 119e0ed

Please sign in to comment.