├── .gitignore
├── CONTRIBUTING.md
├── README.md
├── articles.md
├── authors
├── jallardice.json
└── jklein.json
├── message-articles
├── already-defined.md
├── array-literal-notation.md
├── avoid-arguments.md
├── bad-assignment.md
├── bad-constructor.md
├── bad-declaration.md
├── bad-for-in-variable.md
├── catch-leak.md
├── combine-var.md
├── confusing-minuses.md
├── confusing-pluses.md
├── const-redeclared.md
├── dangling-underscore.md
├── debugger.md
├── dot-notation.md
├── duplicate-key.md
├── empty-class.md
├── es5-feature.md
├── es5-option.md
├── escaped-eol.md
├── eval.md
├── exception-assignment.md
├── expected-one-space.md
├── expected-string.md
├── expected-value-param.md
├── extending-native.md
├── extra-comma.md
├── for-in-if.md
├── function-constructor.md
├── function-in-block.md
├── function-in-loop.md
├── function-strict.md
├── get-set-es5.md
├── global-validthis.md
├── hasownproperty.md
├── implied-eval.md
├── init-undefined.md
├── invalid-typeof-value.md
├── invoked-declaration.md
├── leading-decimal.md
├── literal-constructor.md
├── missing-parens.md
├── missing-radix.md
├── missing-strict.md
├── mixed-quotes.md
├── move-parens.md
├── move-var.md
├── nested-comment.md
├── new-side-effects.md
├── not-a-function.md
├── not-a-label.md
├── not-defined.md
├── object-literal-notation.md
├── octal-literal.md
├── out-of-scope.md
├── overriding-constant.md
├── read-only.md
├── redefinition-of-native.md
├── regex-division.md
├── regex-spaces.md
├── reserved-identifier.md
├── return-conditional.md
├── statement-label.md
├── stopping.md
├── subexpression-parens.md
├── todo-comment.md
├── too-many-params.md
├── trailing-decimal.md
├── type-confusion.md
├── unclosed-comment.md
├── unclosed-mega-literal.md
├── unclosed-regex.md
├── unclosed-string.md
├── unexpected-assignment.md
├── unexpected-comment.md
├── unexpected-get-param.md
├── unexpected-increment.md
├── unexpected-sync.md
├── unexpected-with.md
├── unnamed-function.md
├── unnecessary-else.md
├── unnecessary-escapement.md
├── unnecessary-function-parens.md
├── unnecessary-semicolon.md
├── unnecessary-strict.md
├── unregistered-property-name.md
├── unused-expression.md
├── unused-var.md
├── uppercase-constructor.md
├── use-isnan.md
├── use-named-param.md
├── use-or.md
├── use-quote.md
├── valid-trailing-decimal.md
├── variable-delete.md
├── weird-assignment.md
├── weird-relation.md
├── with-strict.md
└── wrap-iife.md
└── option-articles
├── bitwise.md
├── camelcase-jshint.md
├── curly-jshint.md
├── eqeqeq-jshint.md
├── es3-jshint.md
├── forin.md
├── freeze-jshint.md
├── immed-jshint.md
├── indent.md
└── latedef-jshint.md
/.gitignore:
--------------------------------------------------------------------------------
1 | # Annoying OS X files
2 | .DS_Store
3 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # JSLint Error Explanations
2 |
3 | This is the repository for the content of the [JSLint Errors][site] website. If
4 | you're reading this hopefully you're looking to help out by adding an article
5 | for a missing JSLint, JSHint or ESLint error message.
6 |
7 | ## Contributing
8 |
9 | If you would like to add a new explanation or correct a mistake in an existing
10 | one please fork this repository and make your changes in accordance with the
11 | [contribution guidelines][contrib]. All pull requests will be considered.
12 |
13 | If you have a feature request related to the website or API please raise an
14 | issue in this repository. Although only the explanations themselves are tracked
15 | here this is the place for all discussion around the site and API too.
16 |
17 | ## API
18 |
19 | There is a simple API that can be used to find an explanation for linter
20 | messages dynamically. It's designed for integration into IDEs or web UIs. All
21 | responses are served wtih an `Access-Control-Allow-Origin: *` header so you can
22 | request explanations from client-side JavaScript. See the [documentation][api]
23 | for all the details.
24 |
25 | ## FAQ
26 |
27 | - Where did the code for the [website][site] go?
28 |
29 | The website itself is no longer open-source. All content remains open and
30 | licensed under the Creative Commons [Attribution-ShareAlike 3.0
31 | Unported][ccasa3] license.
32 |
33 | - Who can use the API?
34 |
35 | Anyone! There are no restrictions whatsoever but please be sensible. But if you
36 | are planning on making thousands of requests over short periods of time please
37 | let me know or I'll probably throttle you.
38 |
39 | [site]: http://linterrors.com/
40 | [contrib]: CONTRIBUTING.md
41 | [api]: http://linterrors.com/api/
42 | [ccasa3]: http://creativecommons.org/licenses/by-sa/3.0/
43 |
--------------------------------------------------------------------------------
/authors/jallardice.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "James Allardice",
3 | "twitter": "james_allardice",
4 | "github": "jamesallardice",
5 | "gplus": "110229746715330149995",
6 | "gravatar": "321be24529d43c2bacc7167337299e3d",
7 | "bio": "Software engineer at Tesco and orangejellyfish in London. Passionate about React, Node and writing clean and maintainable JavaScript. Uses linters (currently ESLint) every day to help achieve this."
8 | }
9 |
--------------------------------------------------------------------------------
/authors/jklein.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "Jonathan Klein",
3 | "twitter": "jonathanklein",
4 | "github": "jklein",
5 | "gplus": "109491115907466487995",
6 | "gravatar": "72f8175ac13e367bb500dd4da1f1aa32",
7 | "bio": "software engineer at Etsy, focusing on solving web performance and scalability challenges. He started and organizes the Boston Web Performance Meetup Group."
8 | }
9 |
--------------------------------------------------------------------------------
/message-articles/already-defined.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### History
22 |
23 | This warning has existed in two forms across JSLint and JSHint. It was
24 | introduced in the original version of JSLint and has remained in both tools
25 | ever since.
26 |
27 | - In JSLint releases prior to May 2015 and all versions of JSHint the warning
28 | given is *"{a} is already defined"*
29 |
30 | - In JSLint releases from May 2015 and later the warning is *"Redefinition of
31 | '{a}' from line {b}"*
32 |
33 | The situations that produce the warning have not changed despite changes to the
34 | text of the warning itself.
35 |
36 | ### When do I get this error?
37 |
38 | The "{a} is already defined" error is thrown when JSLint or JSHint encounters
39 | **a declaration with an identifier that has been used in a previous
40 | declaration**. This applies to both variable and function declarations. However
41 | it only applies when the declarations appear within the scope of a function
42 | rather than the global scope. In the following example we attempt to declare the
43 | variable `x` twice within the same scope:
44 |
45 |
50 | ```javascript
51 | function test() {
52 | "use strict";
53 | var a = 1,
54 | a = 2;
55 | return a;
56 | }
57 | ```
58 |
59 | ### Why do I get this error?
60 |
61 | This error is raised to highlight a **probable bug**. Your code will most likely
62 | fail to work as expected if you do not resolve this issue.
63 |
64 | Since variable and function declarations are hoisted to the top of the scope in
65 | which they occur the above code is effectively interpreted as a single
66 | declaration followed by two assignments. The variable will retain the value of
67 | the final assignment.
68 |
69 | If your code is similar to the above then it's likely you have mistyped the
70 | identifier of one of the variables. There are no situations in which it makes
71 | sense or is useful to redeclare a variable. Simply rename one of them
72 | appropriately:
73 |
74 |
79 | ```javascript
80 | function test() {
81 | "use strict";
82 | var a = 1,
83 | b = 2;
84 | }
85 | ```
86 |
87 | Alternatively, you may have intended to have two assignments and simply mistyped
88 | a semicolon as a comma. In that case it's also an obvious fix:
89 |
90 |
95 | ```javascript
96 | function test() {
97 | "use strict";
98 | var a = 1;
99 | a = 2;
100 | }
101 | ```
102 |
103 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
104 | [special option syntax][jshintopts]. The identifier of this
105 | warning is **W004**. This means you can tell JSHint to not issue this warning
106 | with the `/*jshint -W004 */` directive.
107 |
108 | [jshintopts]: http://jshint.com/docs/#options
109 |
--------------------------------------------------------------------------------
/message-articles/avoid-arguments.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Avoid arguments.{a}" error is thrown when JSLint, JSHint or ESLint
23 | encounters **a reference to the `callee` or `caller` property of an `arguments`
24 | object**. The text of this warning can therefore be either "Avoid
25 | arguments.callee" or "Avoid arguments.caller". JSHint will only raise this
26 | warning if the `noarg` option is set to `true`. In the following example we have
27 | a simple function that calculates the factorial of each number in an array. It
28 | uses `arguments.callee` to call itself recursively:
29 |
30 |
35 | ```javascript
36 | var numbers = [1, 2, 3, 4, 5];
37 | numbers.map(function (n) {
38 | return n < 1 ? 1 : n * arguments.callee(n - 1);
39 | });
40 | // Returns [1, 2, 6, 24, 120]
41 | ```
42 |
43 | ### Why do I get this error?
44 |
45 | This error is raised to highlight the **use of a deprecated language feature**.
46 | The code will work as expected in most environments at the moment but support
47 | will eventually be dropped.
48 |
49 | The `callee` and `caller` properties of the `arguments` object were useful in
50 | old versions of JavaScript to achieve recursion in anonymous function
51 | expressions as shown in the example above. It works but causes optimization
52 | problems for the interpreter and can have the unfortunate effect of causing the
53 | value of `this` to change within the function.
54 |
55 | To solve these problems ECMAScript 3 introduced the concept of *named* function
56 | expressions. To avoid this warning modify your code to use them instead:
57 |
58 |
63 | ```javascript
64 | var numbers = [1, 2, 3, 4, 5];
65 | numbers.map(function factorial(n) {
66 | "use strict";
67 | return n < 1 ? 1 : n * factorial(n - 1);
68 | });
69 | // Returns [1, 2, 6, 24, 120]
70 | ```
71 |
72 | Notice the addition of the `"use strict"` directive in that example. In
73 | ECMAScript 5 the use of `arguments.callee` and `arguments.caller` were
74 | deprecated and removed from strict mode. Attempting to reference either property
75 | within a function running in strict mode will cause a type error.
76 |
77 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
78 | [special option syntax][jshintopts]. The identifier of this warning is **W059**.
79 | This means you can tell JSHint to not issue this warning with the `/*jshint
80 | -W059 */` directive.
81 |
82 | In ESLint the rule that generates this warning is named `no-caller`. You can
83 | disable it by setting it to `0`, or enable it by setting it to `1`.
84 |
--------------------------------------------------------------------------------
/message-articles/bad-constructor.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Bad constructor" error is thrown when JSLint or JSHint encounters **the
22 | `new` operator followed by a literal value**. In the following example we are
23 | attempting to apply the `new` operator to a numeric literal:
24 |
25 |
30 | ```javascript
31 | var num = new 5();
32 | ```
33 |
34 | ### Why do I get this error?
35 |
36 | In the case of assignment to a function call this error is raised to highlight a
37 | **fatal type error**. Your code will throw an error in all environments if
38 | you do not resolve this issue.
39 |
40 | The `new` operator attempts to invoke the internal `[[Construct]]` property of
41 | its operand ([ES5 §11.2.2][es5-11.2.2]):
42 |
43 | > The production NewExpression : `new` NewExpression is evaluated as follows:
44 | >
45 | > 1. Let ref be the result of evaluating NewExpression.
46 | >
47 | > 2. Let constructor be GetValue(ref).
48 | > 3. If Type(constructor) is not Object, throw a
49 | > TypeError exception.
50 | > 4. If constructor does not implement the [[Construct]]
51 | > internal method, throw a TypeError exception.
52 |
53 | We are particularly interested in steps 3 and 4. In the example above the
54 | operand is a numeric literal and therefore its type is not "Object". As stated
55 | by the third rule this will cause a type error to be thrown.
56 |
57 | If the type of the operand *is* Object but it does not have an internal
58 | `[[Construct]]` method the same thing happens and a type error is thrown in step
59 | 4. JSLint and JSHint can detect this to a point and will issue the same "Bad
60 | constructor" warning if you attempt to apply `new` to an object literal:
61 |
62 |
67 | ```javascript
68 | var num = new {}();
69 | ```
70 |
71 | To avoid this warning simply stop attempting to misuse the `new` operator. It is
72 | only useful for creating instances of a constructor function and has no sensible
73 | meaning when applied to non-function objects or literals.
74 |
75 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
76 | [special option syntax][jshintopts]. The identifier of this warning is **W056**.
77 | This means you can tell JSHint to not issue this warning with the `/*jshint
78 | -W056 */` directive.
79 |
80 | [jshintopts]: http://jshint.com/docs/#options
81 | [es5-11.2.2]: http://es5.github.io/#x11.2.2
82 |
--------------------------------------------------------------------------------
/message-articles/bad-declaration.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### History
22 |
23 | This warning has existed in two forms across the three main linters. It was
24 | introduced in the original version of JSLint and has remained in all three tools
25 | ever since.
26 |
27 | - In JSLint and JSHint prior to version 2.1.4 the warning given is *"Variable
28 | {a} was not declared correctly"*
29 |
30 | - In JSHint 2.1.4 and above the message used is *"You might be leaking a
31 | variable ({a}) here"*
32 |
33 | - ESLint doesn't support this functionality in the same way but will raise the
34 | more generic *"['{a}' is not defined][notdef]"* error in the same situation
35 |
36 | The situations that produce the warning have not changed despite changes to the
37 | text of the warning itself.
38 |
39 | ### When do I get this error?
40 |
41 | The "Variable {a} was not declared correctly error (and the alternative "You
42 | might be leaking a variable ({a}) here" error) is thrown when JSLint and
43 | JSHint encounter **more than one inline assignment**. In this example, we
44 | attempt to assign a string literal to the variables `x`, `y` and `z`:
45 |
46 |
51 | ```javascript
52 | var x = y = z = "example";
53 | ```
54 |
55 | ### Why do I get this error?
56 |
57 | This error is raised to highlight a **potential misunderstanding of the
58 | language**. A relatively common beginner mistake is to use the above code in an
59 | attempt to declare multiple variables and assign a single value to all of them
60 | at the same time. However, the above is actually equivalent to the following:
61 |
62 |
67 | ```javascript
68 | var x;
69 | x = y = z = "example";
70 | ```
71 |
72 | This makes the problem more obvious. Instead of declaring three variables, we
73 | have actually only declared one. `y` and `z` will refer to variables with those
74 | identifiers in ancestor scopes, or, assuming the code is not running in strict
75 | mode, will be created as properties of the global object. If you intended to
76 | declare multiple variables, you can use commas to separate them instead:
77 |
78 |
83 | ```javascript
84 | var x, y, z;
85 | x = y = z = "example";
86 | ```
87 |
88 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
89 | [special option syntax][jshintopts]. The identifier of this warning is **W120**.
90 | This means you can tell JSHint to not issue this warning with the `/*jshint
91 | -W120 */` directive.
92 |
93 | [notdef]: /a-was-used-before-it-was-defined
94 | [jshintopts]: http://jshint.com/docs/#options
95 |
--------------------------------------------------------------------------------
/message-articles/confusing-minuses.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### History
20 |
21 | This warning has existed in a few forms in both JSLint and JSHint. It was
22 | introduced in the original version of JSLint and has remained in both tools ever
23 | since.
24 |
25 | - In JSHint prior to version 1.0.0 the warning given was *"Confusing minusses"*
26 |
27 | - In JSHint 1.0.0 and above the spelling has been corrected and the message
28 | used is now *"Confusing minuses"*
29 |
30 | - JSLint has always used the more generic *"Confusing use of '{a}"* warning in
31 | the same situation
32 |
33 | ### When do I get this error?
34 |
35 | The "Confusing minuses" error is thrown when JSHint encounters **an addition
36 | operator in which the right-hand-side expression is preceded by the unary `-`
37 | operator**. In the following example we attempt to compute the addition of a
38 | numeric literal and the numeric value of a variable:
39 |
40 |
45 | ```javascript
46 | var a = "10",
47 | b = 5 - -a;
48 | ```
49 |
50 | ### Why do I get this error?
51 |
52 | This error is raised to highlight a **potentially confusing piece of code**.
53 | Your code will most likely run as expected but it could cause issues with
54 | maintenance and be confusing to other developers.
55 |
56 | The `-` operator is overloaded in JavaScript. Most commonly it can be seen as
57 | the subtraction operator but it also functions in a unary form as a numeric
58 | casting and negating operator. In this unary form the result of the expression
59 | will be the value of the operand coerced to the Number type and then negated. In
60 | the example above, because the value of `a` is a string that can be converted to
61 | a number, the `+a` expression results in the value `-10` and the value of `b`
62 | ends up as `-5`.
63 |
64 | This behaviour is described in the specification ([ES5
65 | §11.4.7][es5-11.4.7]):
66 |
67 | > The production *UnaryExpression* : `-` *UnaryExpression* is evaluated as
68 | > follows:
69 | > 1. Let *expr* be the result of evaluating UnaryExpression.
70 | > 2. Let *oldValue* be ToNumber(GetValue(*expr*)).
71 | > 3. If *oldValue* is NaN, return NaN.
72 | > 4. Return the result of negating *oldValue*; that is, compute a Number with
73 | > the same magnitude but opposite sign.
74 |
75 | However, when the subtraction operator is used adjacent to the unary `-`
76 | operator an unforunate resemblance to the decrement operator arises. The
77 | decrement operator, `--`, is used to subtract 1 from its operand. It can be used
78 | as a postfix or prefix operator which means it can appear after or before its
79 | operand. This makes the above example slightly confusing on first glance.
80 |
81 | To resolve this issue the easiest fix is to wrap the unary expression in
82 | parentheses to disambiguate the `-` characters:
83 |
84 |
89 | ```javascript
90 | var a = "10",
91 | b = 5 - (-a);
92 | ```
93 |
94 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
95 | [special option syntax][jshintopts]. The identifier of this warning is **W006**.
96 | This means you can tell JSHint to not issue this warning with the `/*jshint
97 | -W006 */` directive.
98 |
99 | [es5-11.4.7]: http://es5.github.io/#x11.4.7
100 | [jshintopts]: http://jshint.com/docs/#options
101 |
--------------------------------------------------------------------------------
/message-articles/confusing-pluses.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### History
22 |
23 | This warning has existed in a few forms in both JSLint and JSHint. It was
24 | introduced in the original version of JSLint and has remained in both tools ever
25 | since.
26 |
27 | - In JSHint prior to version 1.0.0 the warning given was *"Confusing plusses"*
28 |
29 | - In JSHint 1.0.0 and above the spelling has been corrected and the message
30 | used is now *"Confusing pluses"*
31 |
32 | - JSLint has always used the more generic *"Confusing use of '{a}"* warning in
33 | the same situation
34 |
35 | ### When do I get this error?
36 |
37 | The "Confusing pluses" error is thrown when JSHint encounters **an addition
38 | operator in which the right-hand-side expression is preceded by the unary `+`
39 | operator**. In the following example we attempt to compute the addition of a
40 | numeric literal and the numeric value of a variable:
41 |
42 |
47 | ```javascript
48 | var a = "5",
49 | b = 5 + +a;
50 | ```
51 |
52 | ### Why do I get this error?
53 |
54 | This error is raised to highlight a **potentially confusing piece of code**.
55 | Your code will most likely run as expected but it could cause issues with
56 | maintenance and be confusing to other developers.
57 |
58 | The `+` operator is overloaded in JavaScript. Most commonly it can be seen as
59 | the addition operator but it also functions in a unary form as a numeric casting
60 | operator. In this unary form the result of the expression will be the value of
61 | the operand coerced to the Number type. In the example above, because the value
62 | of `a` is a string that can be converted to a number, the `+a` expression
63 | results in the value `5` and the value of `b` ends up as `10`.
64 |
65 | This behaviour is described in the specification ([ES5
66 | §11.4.6][es5-11.4.6]):
67 |
68 | > The production *UnaryExpression* : `+` *UnaryExpression* is evaluated as
69 | > follows:
70 | > 1. Let *expr* be the result of evaluating *UnaryExpression*.
71 | > 2. Return ToNumber(GetValue(*expr*))
72 |
73 | However, when the addition operator is used adjacent to the unary `+` operator
74 | an unforunate resemblance to the increment operator arises. The increment
75 | operator, `++`, is used to add 1 to its operand. It can be used as a postfix or
76 | prefix operator which means it can appear after or before its operand. This
77 | makes the above example slightly confusing on first glance, especially as the
78 | `++` operator is far more commonly used than the unary `+` operator.
79 |
80 | To resolve this issue the easiest fix is to wrap the unary expression in
81 | parentheses to disambiguate the `+` characters:
82 |
83 |
88 | ```javascript
89 | var a = "5",
90 | b = 5 + (+a);
91 | ```
92 |
93 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
94 | [special option syntax][jshintopts]. The identifier of this
95 | warning is **W007**. This means you can tell JSHint to not issue this warning
96 | with the `/*jshint -W007 */` directive.
97 |
98 | [es5-11.4.6]: http://es5.github.io/#x11.4.6
99 | [jshintopts]: http://jshint.com/docs/#options
100 |
--------------------------------------------------------------------------------
/message-articles/const-redeclared.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "const '{a}' has already been declared" error is thrown when JSHint
21 | encounters **a constant declaration with an identifier that has already been
22 | used in a previous constant declaration**. In the following example we declare a
23 | constant `CONST_1` and then attempt to declare a second constant with the same
24 | identifier:
25 |
26 |
31 | ```javascript
32 | /*jshint esnext: true */
33 | const CONST_1 = 10;
34 | const CONST_1 = 20;
35 | ```
36 |
37 | Notice the use of the `esnext` option. When relying upon ECMAScript 6 features
38 | such as constants you should always set this option so JSHint doesn't raise
39 | unnecessary warnings. Also note that ESLint will raise a warning in the same
40 | scenario but uses the more generic "[{a} is already defined][alreadydef]"
41 | message. See that page for more details.
42 |
43 | ### Why do I get this error?
44 |
45 | This error is raised to highlight a **fatal JavaScript type error**. Your code
46 | will fail to run if you do not resolve this error. Mozilla Developer Network
47 | offers the following note:
48 |
49 | > The value of a constant cannot change through re-assignment, and a constant
50 | > cannot be re-declared.
51 |
52 | You can fix this issue by ensuring each constant declaration uses a unique
53 | identifier:
54 |
55 |
60 | ```javascript
61 | /*jshint esnext: true */
62 | const CONST_1 = 10;
63 | const CONST_2 = 20;
64 | ```
65 |
66 | However, since browser support for the `const` statement is limited and most
67 | implementations currently differ significantly from the upcoming ECMAScript 6
68 | specification, it's recommended that you don't use it all, and simply use the
69 | `var` statement instead. A common convention to indicate a variable with a value
70 | that shouldn't change is to give that variable an identifier made up of
71 | uppercase characters, as has been done in the previous examples.
72 |
73 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
74 | [special option syntax][jshintopts]. Since this message relates to a fatal
75 | syntax error you cannot disable it.
76 |
77 | [alreadydef]: /a-is-already-defined
78 | [jshintopts]: http://jshint.com/docs/#options
79 |
--------------------------------------------------------------------------------
/message-articles/dangling-underscore.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Unexpected dangling '_' in '{a}'" error is thrown when JSLint, JSHint or
23 | ESLint encounters **an identifier that begins or ends with the underscore
24 | character**. JSHint will only raise this warning **when the `nomen` option is
25 | set to `true`**. ESLint only raises this warning for **variable and function
26 | identifiers** and not for object property identifiers. In the following example
27 | we use several such identifiers:
28 |
29 |
34 | ```javascript
35 | /*jshint nomen: true */
36 | var _x = 10,
37 | y = {
38 | z_: 20
39 | };
40 |
41 | function _test() {
42 | "use strict";
43 | return true;
44 | }
45 | ```
46 |
47 | ### Why do I get this error?
48 |
49 | This error is raised to highlight a **lack of convention**. Your code will run
50 | without error if you do not change it, but could be confusing to other
51 | developers, and could also indicate a lack of understanding of the language.
52 |
53 | Identifiers prefixed with the underscore character are often used to indicate a
54 | private variable. Since JavaScript doesn't have a real notion of "private", this
55 | can be misleading.
56 |
57 | If you're using JSLint, you can fix the error by setting the `nomen` (short for
58 | nomenclature) option to true. Conversely, if you're using JSHint, you can simply
59 | remove the same option:
60 |
61 |
66 | ```js
67 | /*jslint nomen: true */
68 | var _x = 10,
69 | y = {
70 | z_: 20
71 | };
72 |
73 | function _test() {
74 | "use strict";
75 | return true;
76 | }
77 | ```
78 |
79 | Alternatively, you can simply remove the underscore character from the start or
80 | end of your identifiers (note that use of this character elsewhere in
81 | identifiers is accepted):
82 |
83 |
88 | ```js
89 | /*jshint nomen: true */
90 | var x = 10,
91 | y = {
92 | z: 20
93 | };
94 |
95 | function test_with_underscores() {
96 | "use strict";
97 | return true;
98 | }
99 | ```
100 |
101 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
102 | [special option syntax][jshintopts]. The identifier of this warning is **W105**.
103 | This means you can tell JSHint to not issue this warning with the `/*jshint
104 | -W105 */` directive.
105 |
106 | [es5-12.2]: http://es5.github.com/#x12.2
107 | [jshintopts]: http://jshint.com/docs/#options
108 |
--------------------------------------------------------------------------------
/message-articles/debugger.md:
--------------------------------------------------------------------------------
1 |
25 |
26 | ### History
27 |
28 | This warning has existed in various forms in JSLint, JSHint and ESLint. It was
29 | introduced in the original version of JSLint and has remained in all three
30 | linters ever since.
31 |
32 | - In JSLint the warning given is "Unexpected 'debugger'"
33 |
34 | - In JSHint prior to version 1.0.0 the message used is "All 'debugger'
35 | statements should be removed"
36 |
37 | - In JSHint version 1.0.0 and above the message is "Forgotten 'debugger'
38 | statement?"
39 |
40 | - In ESLint the message has always been "Unexpected 'debugger' statement"
41 |
42 | The situations that produce the warning have not changed despite changes to the
43 | text of the warning itself.
44 |
45 | ### When do I get this error?
46 |
47 | The "All 'debugger' statements should be removed" error, and the alternatives
48 | "Forgotten 'debugger' statement" and "Unexpected 'debugger'", is thrown when
49 | JSLint, JSHint or ESLint encounters a **`debugger` statement**. The following
50 | example is completely useless but is the minimum program that will generate this
51 | error:
52 |
53 |
58 | ```javascript
59 | debugger;
60 | ```
61 |
62 | ### Why do I get this error?
63 |
64 | This error is raised to highlight a **lack of convention** and a **possible
65 | oversight**. Your code will run without error but it will probably not behave
66 | the way you want it to in a production environment. The `debugger` statement is
67 | used to tell the JavaScript engine to open a debugger if one is available and
68 | treat the statement as a breakpoint ([ES5 §12.15][es5-12.15]):
69 |
70 | > Evaluating the *DebuggerStatement* production may allow an implementation to
71 | > cause a breakpoint when run under a debugger. If a debugger is not present or
72 | > active this statement has no observable effect.
73 |
74 | This can be useful during development to get an insight into how your code
75 | behaves, or to inspect the value of variables at runtime. However it's highly
76 | unlikely that you want to keep debugger statements in production code. For that
77 | reason, JSLint, JSHint and ESLint prefer them to be removed.
78 |
79 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
80 | [special option syntax][jshintopts]. The identifier of this warning is **W087**.
81 | This means you can tell JSHint to not issue this warning with the `/*jshint
82 | -W087 */` directive.
83 |
84 | In ESLint the rule that generates this warning is named `no-debugger`. You can
85 | disable it by setting it to `0`, or enable it by setting it to `1`.
86 |
87 | [es5-12.15]: http://es5.github.com/#x12.15
88 | [jshintopts]: http://jshint.com/docs/#options
89 |
--------------------------------------------------------------------------------
/message-articles/dot-notation.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "['{a}'] is better written in dot notation" error is thrown when JSLint,
23 | JSHint or ESLint encounters an attempt to **access a property using a string
24 | literal within a pair of square brackets when the property name is not a
25 | reserved word**. In the following example we attempt to access the `prop`
26 | property of the `x` object:
27 |
28 |
33 | ```javascript
34 | var x = {
35 | prop: 10
36 | },
37 | y = x["prop"];
38 | ```
39 |
40 | ### Why do I get this error?
41 |
42 | This error is raised to highlight a **unnecessarily verbose and potentially
43 | confusing piece of code**. It is very common in many programming languages to
44 | use dot notation when referring to properties of an object. There is no problem
45 | with either syntax, and both will work in all environments. However, by using
46 | dot notation where possible, you can save three characters every time. Here's
47 | the above snippet, this time with dot notation:
48 |
49 |
54 | ```javascript
55 | var x = {
56 | prop: 10
57 | },
58 | y = x.prop;
59 | ```
60 |
61 | However, it's important to remember that you have to use the square bracket
62 | notation if you want to access a property whose identifier is a reserved word.
63 | JSLint and JSHint will not raise this error in that situation. In the following
64 | example, `x` has a property with the identifier `class`. Notice that JSLint does
65 | not throw an error, even though we are using square bracket notation:
66 |
67 |
72 | ```javascript
73 | var x = {
74 | "class": 10
75 | },
76 | y = x["class"];
77 | ```
78 |
79 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
80 | [special option syntax][jshintopts]. The identifier of this warning is **W069**.
81 | This means you can tell JSHint to not issue this warning with the `/*jshint
82 | -W069 */` directive. You can also set the `sub` option to `true`.
83 |
84 | In ESLint the rule that generates this warning is named `dot-notation`. You can
85 | disable it by setting it to `0`, or enable it by setting it to `1`.
86 |
87 | [jshintopts]: http://jshint.com/docs/#options
88 |
--------------------------------------------------------------------------------
/message-articles/duplicate-key.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### History
23 |
24 | This warning has existed in three forms in JSLint, JSHint and ESLint. It was
25 | introduced in the original version of JSLint and has remained in all three
26 | linters ever since.
27 |
28 | - In JSLint the warning given is the generic "Duplicate '{a}'"
29 |
30 | - In JSHint prior to version 1.0.0 the message used was "Duplicate member
31 | '{a}'"
32 |
33 | - In JSHint 1.0.0 and above and ESLint the message is "Duplicate key '{a}'"
34 |
35 | ### When do I get this error?
36 |
37 | The "Duplicate key '{a}'" error, and the alternatives "Duplicate member '{a}'"
38 | and "Duplicate '{a}'", is thrown when JSLint, JSHint or ESLint encounters an
39 | **an object literal that contains more than one property with the same
40 | identifier**. In the following example we attempt to assign an object containing
41 | two properties with the identifier `y` to a variable `x`:
42 |
43 |
48 | ```javascript
49 | var x = {
50 | y: 10,
51 | y: 20
52 | };
53 | ```
54 |
55 | ### Why do I get this error?
56 |
57 | This error is raised to highlight code that **may not work as you expect** and
58 | could possibly cause a **fatal JavaScript syntax error**. In strict mode, your
59 | code will raise a syntax error. Otherwise, it will run without error but you
60 | will most likely get unexpected results.
61 |
62 | The specification states the following, where "*previous*"" is the result of
63 | calling `[[GetOwnProperty]]` on the object in question with the identifier we
64 | are trying to add to it ([ES5 §11.1.5][es5-11.1.5]):
65 |
66 | > If *previous* is not undefined then throw a SyntaxError exception if any of
67 | > the following conditions are true
68 | > a. This production is contained in strict code...
69 | > > ...
70 |
71 | So, when your code is running in strict mode, a syntax error will be thrown if
72 | you attempt to define multiple properties with the same identifier. When not in
73 | strict mode, no error is thrown but usually the latest definition will override
74 | any earlier definitions and you may experience some strange bugs if the naming
75 | was unintentional. Another good reason to always run your code in strict mode.
76 |
77 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
78 | [special option syntax][jshintopts]. The identifier of this warning is **W075**.
79 | This means you can tell JSHint to not issue this warning with the `/*jshint
80 | -W075 */` directive.
81 |
82 | In ESLint the rule that generates this warning is named `no-dupe-keys`. You
83 | can disable it by setting it to `0`, or enable it by setting it to `1`.
84 |
85 | [es5-11.1.5]: http://es5.github.com/#x11.1.5
86 | [jshintopts]: http://jshint.com/docs/#options
87 |
--------------------------------------------------------------------------------
/message-articles/empty-class.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Empty class" error is thrown when JSLint, JSHint (only versions before
21 | 1.0.0) or ESLint encounters **a regular expression literal containing an empty
22 | character class**. The following example defines a regular expression including
23 | an empty character class:
24 |
25 |
30 | ```javascript
31 | var r = /^abc[]/;
32 | ```
33 |
34 | ### Why do I get this error?
35 |
36 | This error is raised to highlight **code that may not work as you expect it
37 | to**. According to the regular expression grammar in the ECMAScript standard,
38 | empty character classes are allowed ([ES5 A.7][es5-a7]):
39 |
40 | > *CharacterClass* ::
41 | > `[` [lookahead ∉ {`^`}] *ClassRanges* `]`
42 | > `[ ^` *ClassRanges* `]`
43 | > *ClassRanges* ::
44 | > [empty]
45 | > *NonemptyClassRanges*
46 |
47 | However, an empty character class can never match anything, meaning the regular
48 | expression in the example above will always fail to match. Since it's unlikely
49 | you intended such behaviour, a warning is raised to highlight the fact that you
50 | may have overlooked something, or simply made a small typo.
51 |
52 | There is no JSLint or JSHint option that can be set to surpress this error. The
53 | best way to resolve it is to simply remove any empty character classes from the
54 | regular expressions in question:
55 |
56 |
61 | ```javascript
62 | var r = /^abc/;
63 | ```
64 |
65 | However, if you really do need an empty character class, you can use the
66 | `RegExp` constructor to create your regular expression:
67 |
68 |
73 | ```javascript
74 | var r = new RegExp("^abc[]");
75 | ```
76 |
77 | In ESLint the rule that generates this warning is named `no-empty-class`. You
78 | can disable it by setting it to `0`, or enable it by setting it to `1`.
79 |
80 | [es5-a7]: http://es5.github.com/#A.7
81 |
--------------------------------------------------------------------------------
/message-articles/es5-feature.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | This is one of many generic error messages uses by JSLint in a number of
19 | situations. Most of these cases are covered in detail by dedicated articles.
20 | Following is a list of situations that will cause JSLint to generate this
21 | message. Where possible the cause is linked to a more detailed page:
22 |
23 | - The use of a [multiline string][multistr]
24 |
25 | - The use of [object property getters or setters][getset]
26 |
27 | [multistr]: /bad-escapement-of-eol-use-option-multistr-if-needed
28 | [getset]: /get-set-are-es5-features
29 |
--------------------------------------------------------------------------------
/message-articles/es5-option.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "ES5 option is now set per default" error is thrown when JSHint (version
21 | 2.0.0 and above only) encounters **the `es5` option with a value of `true`**.
22 | Here's an example in which we set the `es5` option so we can use reserved words
23 | as property identifers (which was not allowed in ES3):
24 |
25 |
30 | ```javascript
31 | /*jshint es5: true */
32 | var x = {
33 | default: 10
34 | };
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **pointless piece of code*. If you're using
40 | JSHint 2.0.0 or above, the `es5` option will be set to `true` by default, due to
41 | the fact that environments supporting the ES5 spec are now far more widespread.
42 |
43 | You can simply remove the option from any JSHint directives or `.jshintrc`
44 | files. Select JSHint version 1.1.0 or below in the following example to see the
45 | difference from when the `es5` option was not on by default:
46 |
47 |
52 | ```javascript
53 | var x = {
54 | default: 10
55 | };
56 | ```
57 |
58 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
59 | [special option syntax][jshintopts]. Since this is an informational JSHint
60 | message, it cannot be disabled.
61 |
62 | [jshintopts]: http://jshint.com/docs/#options
63 |
--------------------------------------------------------------------------------
/message-articles/expected-one-space.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Expected exactly one space between '{a}' and '{b}'" error is thrown when
19 | JSLint encounters **a number of spaces that is not equal to one** in the
20 | following situations (there are numerous other examples that can cause this
21 | error, but these are some of the common ones):
22 |
23 | Between any keyword (such as `if`, `for` or `while`) and its associated opening
24 | parenthesis:
25 |
26 |
31 | ```javascript
32 | var x = true;
33 | if(x) {
34 | x = false;
35 | }
36 | ```
37 |
38 | Between the `function` keyword and its associated opening parenthesis, when the
39 | function is parsed as an expression (but not when it's parsed as a function
40 | declaration):
41 |
42 |
47 | ```javascript
48 | var x = function() {
49 | "use strict";
50 | return true;
51 | };
52 | ```
53 |
54 | Between a closing parenthesis and its associated opening curly brace (such as in
55 | a function statement, `if` statement, `switch` statement etc):
56 |
57 |
62 | ```javascript
63 | var x = true;
64 | if (x){
65 | x = false;
66 | }
67 | ```
68 |
69 | ### Why do I get this error?
70 |
71 | This error is raised to highlight a **lack of convention** and a **deviation
72 | from a coding style**. Your code will run without error if you do not change it,
73 | but may contravene best practices and look messy to other developers. If you are
74 | happy with your coding style, you can tell JSLint to ignore whitespace (or the
75 | lack of whitespace) by setting the `white` option to true:
76 |
77 |
82 | ```javascript
83 | /*jslint white: true */
84 | var x = true;
85 | if (x){
86 | x = false;
87 | }
88 | ```
89 |
90 | However, if you are using JSLint to [enforce a consistent style][style], you
91 | will probably want to listen to what the error tells you, and just make sure you
92 | always use the correct whitespace:
93 |
94 |
99 | ```javascript
100 | var x = true;
101 | if (x){
102 | x = false;
103 | }
104 | ```
105 |
106 | [style]: http://globaldev.co.uk/2012/11/maintaining-consistent-javascript-with-jslint
107 |
--------------------------------------------------------------------------------
/message-articles/expected-string.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Expected a string and instead saw '{a}'" error is thrown when JSLint
19 | encounters **a comparison operator in which one of the operands is a `typeof`
20 | expression and the other operand is not a string literal**. In the following
21 | example we are checking whether a variable is a string:
22 |
23 |
28 | ```javascript
29 | var STRING_TYPE = "string";
30 | function demo(a) {
31 | "use strict";
32 | return typeof a === STRING_TYPE;
33 | }
34 | ```
35 |
36 | The error is also raised when JSLint encounters **an unquoted JSON property**,
37 | but only when in JSON parsing mode. JSLint enters JSON mode when the first
38 | character of its input is `{` or `[`. In the following example the property `b`
39 | should be enclosed in double quotes:
40 |
41 |
46 | ```javascript
47 | {
48 | "a": 1,
49 | b: 2
50 | }
51 | ```
52 |
53 | ### Why do I get this error?
54 |
55 | In the case of the `typeof` comparison this error is raised to highlight a
56 | **potentially confusing piece of code**. The code is perfectly valid and will
57 | work in all cases, but could be difficult to read or understand at first glance.
58 | If you want to store possible `typeof` values instead of comparing to literals,
59 | you can safely ignore this warning. To avoid this message simply replace the
60 | reference with the string literal it represents:
61 |
62 |
67 | ```javascript
68 | function demo(a) {
69 | "use strict";
70 | return typeof a === "string";
71 | }
72 | ```
73 |
74 | In the case of unquoted JSON property identifer this error is raised to
75 | highlight a **fatal syntax error**. The [JSON specification][json] states that
76 | property identifiers must be wrapped in double quotes:
77 |
78 |
83 | ```javascript
84 | {
85 | "a": 1,
86 | "b": 2
87 | }
88 | ```
89 |
90 | [json]: http://json.org/
91 |
--------------------------------------------------------------------------------
/message-articles/expected-value-param.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Expected parameter (value) in set '{a}' function" error is thrown when
19 | JSLint encounters **property setter function in which the first parameter is not
20 | named `value`**. In the following example we create an object `x` with a getter
21 | and setter. The getter will always return half of the set value:
22 |
23 |
28 | ```javascript
29 | var x = {
30 | actual: 10,
31 | get y() {
32 | "use strict";
33 | return this.actual / 2;
34 | },
35 | set y() {
36 | "use strict";
37 | this.actual = val;
38 | }
39 | };
40 | ```
41 |
42 | ### Why do I get this error?
43 |
44 | This error is raised to highlight a **lack of convention**. Your code will run
45 | without error if you do not change it, but could be confusing to other
46 | developers. ECMAScript 5 added new syntax for object property getter and setter
47 | functions. The specification states the following in reference to setters ([ES5
48 | §8.6.1][es5-8.6.1]):
49 |
50 | > The function’s [[Call]] internal method... is called with an arguments list
51 | > containing the assigned value as its sole argument each time a set access of
52 | > the property is performed.
53 |
54 | By convention, this single argument should be named `value`, since it will be
55 | used to set the value of something. To fix this error simply rename the
56 | parameter accordingly:
57 |
58 |
63 | ```javascript
64 | var x = {
65 | actual: 10,
66 | get y() {
67 | "use strict";
68 | return this.actual / 2;
69 | },
70 | set y(value) {
71 | "use strict";
72 | this.actual = value;
73 | }
74 | };
75 | ```
76 |
77 | [es5-8.6.1]: http://es5.github.com/#x8.6.1
78 |
--------------------------------------------------------------------------------
/message-articles/extending-native.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### When do I get this error?
22 |
23 | The "Extending prototype of native object: '{a}'" error, and the alternative
24 | "{a} prototype is read only, properties should not be added" error, is thrown
25 | when JSHint (only versions 2.3.0 and above) or ESLint encounters **a assignment
26 | to a property of the `prototype` of a native object*. JSHint will only raise
27 | this warning if the `freeze` option is set to `true`. The following example
28 | defines a `reverse` method on the native `String` prototype:
29 |
30 |
35 | ```javascript
36 | /*jshint freeze: true */
37 | String.prototype.reverse = function () {
38 | "use strict";
39 | return this.split("").reverse().join("");
40 | };
41 | ```
42 |
43 | ESLint will also issue the warning when the `Object.defineProperty` method is
44 | used. JSHint does not warn in this situation:
45 |
46 |
51 | ```javascript
52 | /*jshint freeze: true */
53 | Object.defineProperty(String.prototype, "reverse", {
54 | value: function () {
55 | "use strict";
56 | return this.split("").reverse().join("");
57 | }
58 | });
59 | ```
60 |
61 | *Side note*: the implementation of string reversal above is naive because it
62 | fails to take into account the way characters are encoded internally in
63 | JavaScript. See [this Stack Overflow answer][reverse] for a great explanation.
64 |
65 | ### Why do I get this error?
66 |
67 | This error is raised to highlight the use of a technique commonly regarded as
68 | **bad practice**. By defining custom properties on native prototypes you can
69 | easily introduce problems in old browsers (in particular Internet Explorer 8 and
70 | below). The first pattern shown above will result in an enumerable property on
71 | `String.prototype`. If this is done to `Object.prototype` the new property will
72 | be produced by the `for...in` construct causing unexpected iterations of the
73 | loop.
74 |
75 | It's also very easy to accidentally shadow custom native prototype methods. For
76 | example, imagine you have defined a `count` method on `Object.prototype` which
77 | returns the number of properties an object has. If any object defines its own
78 | `count` property as part of the program logic the prototype method will be
79 | shadowed and inaccessible via the normal member operator. This makes it easy to
80 | introduce bugs and can also affect third party code.
81 |
82 | In ESLint the rule that generates this warning is named `no-extend-native`. You
83 | can disable it by setting it to `0`, or enable it by setting it to `1`.
84 |
85 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
86 | [special option syntax][jshintopts]. The identifier of this warning is **W121**.
87 | This means you can tell JSHint to not issue this warning with the `/*jshint
88 | -W121 */` directive. You can also set the `freeze` option to `false`.
89 |
90 | [reverse]: http://stackoverflow.com/questions/958908/how-do-you-reverse-a-string-in-place-in-javascript/16776621#16776621
91 | [jshintopts]: http://jshint.com/docs/#options
92 |
--------------------------------------------------------------------------------
/message-articles/function-constructor.md:
--------------------------------------------------------------------------------
1 |
22 |
23 | ### History
24 |
25 | This warning has existed in two forms in JSLint, JSHint and ESLint. It was
26 | introduced in the original version of JSLint and has remained in all three
27 | linters ever since.
28 |
29 | - In JSLint and JSHint prior to version 1.0.0 the warning given is "The
30 | Function constructor is eval"
31 |
32 | - In JSHint 1.0.0 and above the message used is "The Function constructor is a
33 | form of eval"
34 |
35 | - In ESLint the messages has always been "The Function constructor is eval"
36 |
37 | ### When do I get this error?
38 |
39 | The "The Function constructor is eval" error (and the alternative "The Function
40 | constructor is a form of eval" error) is thrown when JSLint, JSHint or ESLint
41 | encounters **a call to the `Function` constructor preceded by the `new`
42 | operator**. Here's a simple example which defines a function to add two numbers:
43 |
44 |
49 | ```javascript
50 | var add = new Function("a", "b", "return a + b");
51 | ```
52 |
53 | ### Why do I get this error?
54 |
55 | This error is raised to highlight a **bad practice**. By passing a string to the
56 | `Function` constructor you are requiring the engine to parse that string much in
57 | the way it has to when you call the `eval` function. For full details of why
58 | this is a problem, see the article on the related "[eval is evil][eval]"
59 | message.
60 |
61 | In simple cases like that of our example above, you can fix the issue by using a
62 | function declaration or function expression:
63 |
64 |
69 | ```javascript
70 | var add = function (a, b) {
71 | "use strict";
72 | return a + b;
73 | };
74 | ```
75 |
76 | In more advanced cases where you really need to use the `Function` constructor,
77 | you can set the `evil` option to `true` to prevent both JSLint and JSHint from
78 | complaining about it:
79 |
80 |
85 | ```javascript
86 | /*jslint evil: true */
87 | var add = new Function("a", "b", "return a + b");
88 | ```
89 |
90 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
91 | [special option syntax][jshintopts]. The identifier of this warning is **W054**.
92 | This means you can tell JSHint to not issue this warning with the `/*jshint
93 | -W054 */` directive.
94 |
95 | In ESLint the rule that generates this warning is named `no-new-func`. You can
96 | disable it by setting it to `0`, or enable it by setting it to `1`.
97 |
98 | [eval]: /eval-is-evil
99 | [jshintopts]: http://jshint.com/docs/#options
100 |
--------------------------------------------------------------------------------
/message-articles/function-strict.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Use the function form of 'use strict'" error is thrown when JSLint, JSHint
23 | or ESLint encounters a **strict mode directive in the outermost scope of the
24 | code**. In the following example we use a strict mode directive in the global
25 | scope to ensure the entire program runs in strict mode:
26 |
27 |
32 | ```javascript
33 | "use strict";
34 | function example() {
35 | return true;
36 | }
37 | ```
38 |
39 | ### Why do I get this error?
40 |
41 | This error is raised to highlight a **potentially dangerous piece of code**.
42 | It's common and good practice to concatenate multiple JavaScript files into one
43 | to reduce HTTP requests in production environments. If one of those files has a
44 | global strict mode directive and others do not, the concatenation would result
45 | in all scripts running in strict mode. If one the those scripts depends upon
46 | features that are disallowed in strict mode you may run into errors. Consider
47 | the following example which shows the previous script concatentated with another
48 | that relies upon features that are illegal in strict mode:
49 |
50 |
55 | ```javascript
56 | "use strict";
57 | function example() {
58 | return true;
59 | }
60 | function another(a) {
61 | return 010; // Octal literal, illegal in strict mode
62 | }
63 | ```
64 |
65 | This example will cause a syntax error since octal literals are not allowed in
66 | strict mode. If we want to use strict mode in our script and still be able to
67 | concatenate it with others we need to ensure our strict mode directive is not in
68 | the global scope. Since JavaScript only has function scope this means we need to
69 | place the directive within a function:
70 |
71 |
76 | ```javascript
77 | function example() {
78 | "use strict";
79 | return true;
80 | }
81 | ```
82 |
83 | This has the added benefit of allowing you to control exactly which parts of
84 | your own script run in strict mode. However, a common technique is to wrap your
85 | entire program in an immediately invoked function expression to constrain it to
86 | its own function scope and help prevent pollution of the global scope.
87 |
88 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
89 | [special option syntax][jshintopts]. The identifier of this warning is **W069**.
90 | This means you can tell JSHint to not issue this warning with the `/*jshint
91 | -W097 */` directive. You can also set the `sub` option to `true`.
92 |
93 | In ESLint the rule that generates this warning is named `no-global-strict`. You
94 | can disable it by setting it to `0`, or enable it by setting it to `1`.
95 |
96 | [jshintopts]: http://jshint.com/docs/#options
97 |
--------------------------------------------------------------------------------
/message-articles/get-set-es5.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### History
20 |
21 | This warning has existed in two forms across JSLint and JSHint. It was
22 | introduced in May 2011 version of JSLint and remained in both tools for a period
23 | of time.
24 |
25 | - In JSLint between May 2011 and August 2013 the message used was the generic
26 | "[This is an ES5 feature][es5]"
27 |
28 | - Before May 2011 and after August 2013 this functionality is not supported in
29 | JSLint
30 |
31 | - In JSHint prior to version 2.0.0 the message used was "get/set are ES5
32 | features"
33 |
34 | - In JSHint 2.0.0 and above this functionality is not supported
35 |
36 | ### When do I get this error?
37 |
38 | The "get/set are ES5 features" error, and the alternative "This is an ES5
39 | feature", is thrown when JSHint or JSLint encounters **an object property getter
40 | or setter**. In the following example we create an object `x` with a getter and
41 | setter. The getter is intended to always return half of the set value:
42 |
43 |
49 | ```javascript
50 | var x = {
51 | actual: 10,
52 | get x () {
53 | "use strict";
54 | return this.actual / 2;
55 | },
56 | set x (value) {
57 | "use strict";
58 | this.actual = value;
59 | }
60 | };
61 | ```
62 |
63 | ### Why do I get this error?
64 |
65 | This error is raised to highlight the use of **a newer language feature that
66 | might not be supported** in all the environments in which your code should run.
67 | In particular, various older browsers will be likely to throw syntax errors when
68 | parsing your script.
69 |
70 | ECMAScript 5 added support for object property getters and setters as a
71 | mechanism for running a function on property access and modification ([ES5
72 | §11.1.5][es5-11.1.5]):
73 |
74 | > *PropertyAssignment* :
75 | > *PropertyName* : *AssignmentExpression*
76 | > `get` *PropertyName* `( ) {` *FunctionBody* `}`
77 | > `set` *PropertyName* `(` *PropertySetParameterList* `)
78 | {` *FunctionBody* `}`
79 |
80 | If you're sure that your code doesn't need to run in older browsers that don't
81 | support the ES5 getter/setter syntax, you can fix this error by setting the
82 | `es5` option to `true`:
83 |
84 |
90 | ```javascript
91 | /*jslint es5: true */
92 | /*jshint es5: true */
93 | var x = {
94 | actual: 10,
95 | get x () {
96 | "use strict";
97 | return this.actual / 2;
98 | },
99 | set x (value) {
100 | "use strict";
101 | this.actual = value;
102 | }
103 | };
104 | ```
105 |
106 | [es5]: /this-is-an-es5-feature
107 | [es5-11.1.5]: http://es5.github.com/#x11.1.5
108 |
--------------------------------------------------------------------------------
/message-articles/global-validthis.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Option 'validthis' can't be used in a global scope" error is thrown when
21 | JSHint encounters **the `validthis` option in a global scope**. Here's a silly
22 | example in which we declare a function that is intended to be invoked in the
23 | context of an object:
24 |
25 |
30 | ```javascript
31 | /*jshint validthis: true */
32 | function example() {
33 | "use strict";
34 | this.x = 10;
35 | }
36 |
37 | var obj = {};
38 | example.call(obj);
39 | ```
40 |
41 | ### Why do I get this error?
42 |
43 | This error is raised to highlight a **breach of JSHint rules**. Your code will
44 | most likely run without error if you do not fix this issue, but you are breaking
45 | the rules of JSHint and will be unable to validate the rest of your code.
46 |
47 | The `validthis` option is used to indicate to JSHint that a function including
48 | the use of this is not going to violate the rules of strict mode. Since this
49 | applies only to functions, it makes no sense to define this option in the global
50 | scope. You should only use it (in function scope) when you are certain the
51 | function will be called with a context. Here's what the [JSHint docs][validthis]
52 | have to say:
53 |
54 | > This option suppresses warnings about possible strict violations when the code
55 | > is running in strict mode and you use `this` in a non-constructor function.
56 | > You should use this option—in a function scope only—when you are positive that
57 | > your use of `this` is valid in the strict mode (for example, if you call your
58 | > function using `Function.call`).
59 | >
60 | > **Note**: This option can be used only inside of a function scope. JSHint will
61 | > fail with an error if you will try to set this option globally.
62 |
63 | To resolve this issue, you simply need to move the directive including the
64 | `validthis` option into the function. You will need it in each function that
65 | runs in strict mode and contains references to `this`:
66 |
67 |
72 | ```javascript
73 | function example() {
74 | /*jshint validthis: true */
75 | "use strict";
76 | this.x = 10;
77 | }
78 |
79 | var obj = {};
80 | example.call(obj);
81 | ```
82 |
83 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
84 | [special option syntax][jshintopts]. Since this message relates to JSHint error
85 | rather than a warning it is not possible to disable it.
86 |
87 | [validthis]: http://jshint.com/docs/options/#validthis
88 | [jshintopts]: http://jshint.com/docs/#options
89 |
--------------------------------------------------------------------------------
/message-articles/hasownproperty.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "'hasOwnProperty' is a really bad name" error is thrown when JSHint
21 | encounters **an assignment to an object property with the identifier
22 | `hasOwnProperty`**. This applies to both object literals and to normal
23 | assignment statements. In the following example we define an object with a
24 | property called `hasOwnProperty`:
25 |
26 |
31 | ```javascript
32 | var demo = {
33 | hasOwnProperty: 1
34 | };
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight **confusing code that could cause problems in
40 | the future**. Your code may run as expected but it's likely to cause issues with
41 | maintenance and be confusing to other developers.
42 |
43 | Most objects in JavaScript have access (via inheritance from `Object.prototype`)
44 | to the `hasOwnProperty` method which is used to check whether a given property
45 | is defined on a given object. This method is commonly used within `for...in`
46 | loops to ensure only enumerable properties of the object in question are
47 | handled, and not enumerable properties of objects further down its prototype
48 | chain. See the somewhat related "[The body of a for in should be wrapped in an
49 | if statement to filter unwanted properties from the prototype][forin]" error for
50 | more details:
51 |
52 |
57 | ```javascript
58 | /*global doSomething */
59 | var me = {
60 | name: "James",
61 | age: 23
62 | };
63 |
64 | for (var prop in me) {
65 | if (me.hasOwnProperty(prop)) {
66 | doSomething(prop);
67 | }
68 | }
69 | ```
70 |
71 | In that example, were you to add a property `hasOwnProperty: 1` to `me`, the
72 | guard in the `for...in` loop would fail with an error telling you that
73 | `hasOwnProperty` is not a function. If the value of your custom `hasOwnProperty`
74 | is a function then it will be invoked and the code may work but would be very
75 | misleading to anyone else reading.
76 |
77 | The solution to this error is to simply not use `hasOwnProperty` as a property
78 | identifer. If you are concerned that the value of `hasOwnProperty` is no longer
79 | the native function you may want to call the native function in the context of
80 | your object in `for...in` loop guards:
81 |
82 |
87 | ```javascript
88 | /*global doSomething */
89 | var me = {
90 | name: "James",
91 | age: 23,
92 | hasOwnProperty: 1 // This would cause the previous example to fail
93 | };
94 |
95 | for (var prop in me) {
96 | if (Object.hasOwnProperty.call(me, prop)) { // Use the real hasOwnProperty
97 | doSomething(prop);
98 | }
99 | }
100 | ```
101 |
102 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
103 | [special option syntax][jshintopts]. The identifier of this
104 | warning is **W001**. This means you can tell JSHint to not issue this warning
105 | with the `/*jshint -W001 */` directive.
106 |
107 | [forin]: /the-body-of-a-for-in-should-be-wrapped-in-an-if-statement
108 | [jshintopts]: http://jshint.com/docs/#options
109 |
--------------------------------------------------------------------------------
/message-articles/implied-eval.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### History
23 |
24 | This warning has existed in two forms across the three main linters. It was
25 | introduced in the original version of JSLint and has remained in all three tools
26 | ever since.
27 |
28 | - In JSLint and JSHint prior to version 1.0.0 the warning given is *"Implied
29 | eval is evil. Pass a function instead of a string"*
30 |
31 | - In JSHint 1.0.0 and above the message used is *"Implied eval. Consider
32 | passing a function instead of a string"*
33 |
34 | - In ESLint the message has always been *"Implied eval. Consider passing a
35 | function instead of a string"*
36 |
37 | The situations that produce the warning have not changed despite changes to the
38 | text of the warning itself.
39 |
40 | ### When do I get this error?
41 |
42 | The "Implied eval is evil. Pass a function instead of a string" error (and
43 | the alternative "Implied eval. Consider passing a function instead of a
44 | string" error) is thrown when JSLint, JSHint and ESLint encounter **a call to
45 | `setTimeout` or `setInterval` in which the first argument is a string**. Here's
46 | an example that should pop up a browser alert after one second:
47 |
48 |
53 | ```javascript
54 | /*jslint browser: true */
55 | setTimeout("alert('Hello!');", 1000);
56 | ```
57 |
58 | ### Why do I get this error?
59 |
60 | This error is raised to highlight a **bad practice** and a possible
61 | **misunderstanding of the language**. By passing a string to `setTimeout` or
62 | `setInterval` you are adding significant extra work for the engine. It has to
63 | parse that string as a complete program, akin to the `eval` function. For full
64 | details of why this is a problem see the article on the related message: "[eval
65 | is evil][evil]".
66 |
67 | You can fix this issue by simply passing a function to `setTimeout` or
68 | `setInterval` instead of a string. In a situation like that of the example
69 | above, you can achieve this by passing an anonymous function:
70 |
71 |
76 | ```javascript
77 | /*jslint browser: true, devel: true */
78 | setTimeout(function () {
79 | "use strict";
80 | alert('Hello!');
81 | }, 1000);
82 | ```
83 |
84 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
85 | [special option syntax][jshintopts]. The identifier of this warning is **W066**.
86 | This means you can tell JSHint to not issue this warning with the `/*jshint
87 | -W066 */` directive.
88 |
89 | In ESLint the rule that generates this warning is named `no-implied-eval`. You
90 | can disable it by setting it to `0`, or enable it by setting it to `1`.
91 |
92 | [evil]: /eval-is-evil
93 | [jshintopts]: http://jshint.com/docs/#options
94 |
--------------------------------------------------------------------------------
/message-articles/invalid-typeof-value.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Invalid typeof value '{a}'" error is thrown when JSHint encounters **a
21 | comparison with a `typeof` expression on one side and an invalid string literal
22 | on the other**. In the following example we have a function that will return
23 | `true` if the argument is of type `"bool"`:
24 |
25 |
30 | ```javascript
31 | function demo(a) {
32 | return typeof a === "bool";
33 | }
34 | ```
35 |
36 | This functionality was introduced in JSHint 2.3.0. Prior versions do not raise
37 | any error in this situation. Neither JSLint nor ESLint raises any error in this
38 | situation.
39 |
40 | ### Why do I get this error?
41 |
42 | This error is raised to highlight **code that is unlikely to work as you
43 | expect**. The `typeof` operator returns one of a few possible values that are
44 | given by the ECMAScript specification (although in some situations in certain
45 | browsers it will return one of two extra possibilities). The possible values are
46 | as follows ([ES5 §11.4.3]):
47 |
48 | - `"undefined"` - when the operand has the `undefined` value
49 |
50 | - `"boolean"` - when the operand has a literal boolean value
51 |
52 | - `"string"` - when the operand has a literal string value
53 |
54 | - `"number"` - when the operand has a literal numeric value
55 |
56 | - `"function"` - when the operand is an object and implements the internal
57 | [[Call]] property
58 |
59 | - `"object"` - when the operand has the `null` value or is an object that does
60 | not implement the internal [[Call]] property
61 |
62 | In certain situations the operator could also return `"xml"` or `"unknown"` but
63 | you're unlikely to come across these. JSHint requires that any comparison with a
64 | `typeof` expression uses one of these strings. If a different string is used the
65 | condition will always evaluate to false since it is not possible for the
66 | `typeof` operator to ever return the value you're using. To solve this issue
67 | simply use a valid value:
68 |
69 |
74 | ```javascript
75 | function demo(a) {
76 | return typeof a === "boolean";
77 | }
78 | ```
79 |
80 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
81 | [special option syntax][jshintopts]. The identifier of this warning is **W122**.
82 | This means you can tell JSHint to not issue this warning with the `/*jshint
83 | -W122 */` directive. You can also set the `sub` option to `true`.
84 |
85 | [es5-11.4.3]: https://es5.github.io/#11.4.3
86 | [jshintopts]: http://jshint.com/docs/#options
87 |
--------------------------------------------------------------------------------
/message-articles/leading-decimal.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### History
23 |
24 | This warning has existed in two forms across the three main linters. It was
25 | introduced in the original version of JSLint and has remained in all three tools
26 | ever since.
27 |
28 | - In JSLint versions dated before May 2013 the warning given is *"A leading
29 | decimal point can be confused with a dot: '{a}'"*
30 |
31 | - In JSLint version dated May 2013 and later this message has been replaced
32 | with the more generic *"Unexpected '{a}'"*
33 |
34 | - In JSHint and ESLint the message has always been *"A leading decimal point
35 | can be confused with a dot: '{a}'"*
36 |
37 | The situations that produce the warning have not changed despite changes to the
38 | text of the warning itself.
39 |
40 | ### When do I get this error?
41 |
42 | The "A leading decimal point can be confused with a dot" error is thrown when
43 | JSLint, JSHint and ESLint encounter **a numeric literal preceded by a `.` token
44 | which itself is not preceded by a decimal integer literal**. Here's an example
45 | in which we attempt to assign the value `0.5` to the variable `x`:
46 |
47 |
53 | ```javascript
54 | var x = .5;
55 | ```
56 |
57 | ### Why do I get this error?
58 |
59 | This error is raised to highlight a **potentially confusing piece of code**.
60 | Your code will run without error if you do not address this issue but it could
61 | be confusing to other developers. The ECMAScript standard states that it is
62 | syntactically valid for a numeric literal to begin with a . character ([ES5
63 | Annex 1][es5-a1]):
64 |
65 | > *DecimalLiteral* ::
66 | > *DecimalIntegerLiteral* `.`
67 | > *DecimalDigits*opt *ExponentPart*opt
68 | > `.` *DecimalDigits* *ExponentPart*opt
69 | > *DecimalIntegerLiteral* *ExponentPart*opt
70 |
71 | The second production in the grammar quoted above shows the situation we
72 | encounter in the example at the top of this page. However, since the `.`
73 | character is ambiguous (it's also commonly seen in use as a "member operator",
74 | to access a property of an object), JSLint, JSHint and ESLint prefer the
75 | explicit first production from the above grammar, just to make your code easier
76 | to understand. Therefore to fix this error you can simply prepend a `0` to your
77 | number:
78 |
79 |
85 | ```javascript
86 | var x = 0.5;
87 | ```
88 |
89 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
90 | [special option syntax][jshintopts]. The identifier of this warning is **W008**.
91 | This means you can tell JSHint to not issue this warning with the `/*jshint
92 | -W008 */` directive.
93 |
94 | In ESLint the rule that generates this warning is named `no-floating-decimal`.
95 | You can disable it by setting it to `0`, or enable it by setting it to `1`.
96 |
97 | [es5-11.9.6]: http://es5.github.com/#x11.9.6
98 | [es5-11.9.3]: http://es5.github.com/#x11.9.3
99 | [es5-15.1.2.4]: http://es5.github.com/#x15.1.2.4
100 | [jshintopts]: http://jshint.com/docs/#options
101 |
--------------------------------------------------------------------------------
/message-articles/literal-constructor.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Do not use {a} as a constructor" error is thrown when JSLint, JSHint or
23 | ESLint encounters **a call to `String`, `Number`, `Boolean`, `Math` or `JSON`
24 | preceded by the `new` operator**. In the following example we attempt to assign
25 | some values to variables by invoking these functions as constructors:
26 |
27 |
32 | ```javascript
33 | var str = new String("hello"),
34 | num = new Number(10),
35 | bool = new Boolean(false),
36 | math = new Math(),
37 | json = new JSON({ myProp: 10 });
38 | ```
39 |
40 | ### Why do I get this error?
41 |
42 | This error is raised to highlight a **bad practice** and a piece of code that
43 | **may not work as you intend it to**. It can also highlight a possible **fatal
44 | JavaScript error**. Your code could run without error if you do not change it,
45 | but could be confusing to other developers and could also behave in unexpected
46 | ways.
47 |
48 | The `String`, `Number` and `Boolean` constructor functions return objects of
49 | type `String`, `Number` and `Boolean`, which is rarely what you want. Usually,
50 | you want literal string, number or boolean values, because strictly comparing an
51 | object to a literal will always return false. In the case of these objects, to
52 | fix this error, use literal values rather than their corresponding wrapper
53 | objects:
54 |
55 |
60 | ```javascript
61 | var str = "hello",
62 | num = 10,
63 | bool = false;
64 | ```
65 |
66 | Note that this does not cause you to lose any functionality, since literal
67 | values are internally cast to instances of the appropriate type when you call a
68 | method on them. Also note that you are free to use these functions to perform
69 | type conversions i.e. by invoking them without the `new` operator:
70 |
71 |
76 | ```javascript
77 | var str = String(10), // "10"
78 | num = Number("123"), // 123
79 | bool = Boolean(""); // false
80 | ```
81 |
82 | The case is a little different for the `Math` and `JSON` objects. These two
83 | objects are not functions, and cannot be constructed. Attempts to instantiate
84 | them will result in a type error. If you're trying to serialize an object into a
85 | JSON string, you need to use the `JSON.stringify` method instead:
86 |
87 |
92 | ```javascript
93 | var json = JSON.stringify({ myProp: 10 });
94 | ```
95 |
96 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
97 | [special option syntax][jshintopts]. The identifier of this warning is **W053**.
98 | This means you can tell JSHint to not issue this warning with the `/*jshint
99 | -W053 */` directive.
100 |
101 | [jshintopts]: http://jshint.com/docs/#options
102 |
--------------------------------------------------------------------------------
/message-articles/missing-parens.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### History
21 |
22 | This warning has existed in two forms across the three main linters. It was
23 | introduced in the original version of JSLint and has remained in all three tools
24 | ever since.
25 |
26 | - In JSLint the warning given is the generic *"Missing '{a}'"*
27 |
28 | - In JSHint and ESLint the message used is *"Missing '()' invoking a
29 | constructor"*
30 |
31 | The situations that produce the warning have not changed despite changes to the
32 | text of the warning itself.
33 |
34 | ### When do I get this error?
35 |
36 | The "Missing '()' invoking a constructor" error is thrown when JSLint, JSHint
37 | and ESLint encounter **a `new` expression that is not immediately followed by a
38 | pair of parentheses**. In the following example we create an instance of the
39 | built-in `Date` constructor:
40 |
41 |
47 | ```javascript
48 | var d = new Date;
49 | ```
50 |
51 | ### Why do I get this error?
52 |
53 | This error is raised to highlight a **lack of convention**. Your code will work
54 | without error if you do not resolve this issue but you may be contravening
55 | coding styles and best practices. The ECMAScript 5 specification shows (in a
56 | confusing way) that `new` expressions do not have to be followed by a pair of
57 | parentheses. The parentheses are only required when arguments are being passed
58 | to the constructor ([ES5 §11.2][es5-11.2]):
59 |
60 | > *MemberExpression* :
61 | > ...
62 | > `new` *MemberExpression Arguments*
63 | > *NewExpression* :
64 | > *MemberExpression*
65 | > `new` *NewExpression*
66 | > *Arguments* :
67 | > `( )`
68 | > `(` *ArgumentList* `)`
69 |
70 | The grammar can be a bit confusing, but in essence the above shows that the
71 | *Arguments* nonterminal is optional. If you do not need to pass arguments to the
72 | constructor you can leave it out. However, many style guides would recommend
73 | that the parentheses are always included for consistency, and to make it
74 | immediately clear that an invocation is taking place.
75 |
76 | Consider the fact that omitting the parentheses from a normal (non-constructor)
77 | function invocation will cause the expression to evaluate to a reference to that
78 | function, rather than the return value of it. By missing the parentheses on a
79 | constructor call your code may be less self-explanatory. To fix the issue you
80 | can simply add the missing parentheses:
81 |
82 |
88 | ```javascript
89 | var d = new Date();
90 | ```
91 |
92 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
93 | [special option syntax][jshintopts]. The identifier of this warning is **W058**.
94 | This means you can tell JSHint to not issue this warning with the `/*jshint
95 | -W058 */` directive.
96 |
97 | In ESLint the rule that generates this warning is named `new-parens`.
98 | You can disable it by setting it to `0`, or enable it by setting it to `1`.
99 |
100 | [es5-11.2]: http://es5.github.com/#x11.2
101 | [jshintopts]: http://jshint.com/docs/#options
102 |
--------------------------------------------------------------------------------
/message-articles/missing-radix.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Missing radix parameter" error is thrown when JSLint, JSHint or ESLint
23 | encounters **a call to the `parseInt` function that only has one argument**. As
24 | of JSHint 2.3.0 the warning will only be issued if the `es3` option is set to
25 | `true`. Here's an example:
26 |
27 |
32 | ```javascript
33 | parseInt("10");
34 | ```
35 |
36 | ### Why do I get this error?
37 |
38 | This error is raised to highlight a **potential oversight that could lead to
39 | problems**. The second argument of the `parseInt` function is used to specify a
40 | radix. If no radix is specified, the function can return suprising results. If
41 | the string begins with a `0` it will be interpreted as an octal (base 8) number.
42 | For example, `parseInt("010")` will return `8`, and not `10`. This behaviour was
43 | allowed by the ECMAScript 3 specification. However, here's what the ECMAScript 5
44 | specification has to say ([ES5 §15.1.2.2][es5-15.1.2.2]:
45 |
46 | > The `parseInt` function produces an integer value dictated by interpretation
47 | > of the contents of the string argument according to the specified radix.
48 | > Leading white space in string is ignored. If radix is undefined or 0, it is
49 | > assumed to be 10 except when the number begins with the character pairs `0x`
50 | > or `0X`, in which case a radix of 16 is assumed.
51 |
52 | As of ECMAScript 5, this quirk of `parseInt` has been removed. However, since
53 | it's likely you will want your code to run successfully in older environments
54 | that do not support ES5, you should always pass a radix to `parseInt`:
55 |
56 |
61 | ```javascript
62 | parseInt("10", 10);
63 | ```
64 |
65 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
66 | [special option syntax][jshintopts]. The identifier of this warning is **W065**.
67 | This means you can tell JSHint to not issue this warning with the `/*jshint
68 | -W065 */` directive.
69 |
70 | [es5-15.1.2.2]: http://es5.github.io/#x15.1.2.2
71 | [jshintopts]: http://jshint.com/docs/#options
72 |
--------------------------------------------------------------------------------
/message-articles/missing-strict.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Missing 'use strict' statement" error is thrown when JSLint, JSHint and
23 | ESLint encounter **a function that does not contain the strict mode directive,
24 | and none of whose ancestor scopes contain the strict mode directive**. JSHint
25 | will only raise this warning if the `strict` option is set to `true`. Here's an
26 | example of a function that does not run in strict mode:
27 |
28 |
34 | ```javascript
35 | /*jshint strict: true */
36 | function example() {
37 | return true;
38 | }
39 | ```
40 |
41 | ### Why do I get this error?
42 |
43 | This error is raised to highlight a **lack of convention**. However, as
44 | JavaScript engines move forward, this error will increasingly be helpful as it
45 | should highlight areas of code that may not work as you expect them to, or may
46 | even cause fatal JavaScript errors.
47 |
48 | A `"use strict"` statement is an example of a *directive*, which can appear as
49 | the first statement of a program or a function ([ES5 §14.1][es5-14.1]):
50 |
51 | > A Directive Prologue is the longest sequence of *ExpressionStatement*
52 | > productions occurring as the initial *SourceElement* productions of a
53 | > *Program* or *FunctionBody* and where each *ExpressionStatement* in the
54 | > sequence consists entirely of a *StringLiteral* token followed a semicolon.
55 | > The semicolon may appear explicitly or may be inserted by automatic semicolon
56 | > insertion. A Directive Prologue may be an empty sequence.
57 |
58 | The `"use strict"` directive can be used to force the engine to conform to a
59 | strict subset of the language, as defined in [ES5 Annex C][es5-ac]. It has
60 | become something of a convention to run all JavaScript code in strict mode, to
61 | avoid falling into traps that are apparent in the non-strict language. See the
62 | previous link or the corresponding [MDN article][mdn] for the details of the
63 | differences in strict mode. You can fix this error by simply adding a `"use
64 | strict"` directive to the function, or to an ancestor function:
65 |
66 |
72 | ```javascript
73 | /*jshint strict: true */
74 | function example() {
75 | "use strict";
76 | return true;
77 | }
78 | ```
79 |
80 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
81 | [special option syntax][jshintopts]. This message is treated as an error by
82 | JSHint which means you are unable to prevent it from being issued by ID.
83 |
84 | In ESLint the rule that generates this warning is named `strict`. You can
85 | disable it by setting it to `0`, or enable it by setting it to `1`.
86 |
87 | [es5-14.1]: http://es5.github.com/#x14.1
88 | [es5-ac]: http://es5.github.com/#C
89 | [mdn]: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode
90 | [jshintopts]: http://jshint.com/docs/#options
91 |
--------------------------------------------------------------------------------
/message-articles/mixed-quotes.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Mixed double and single quotes" error is thrown when JSHint encounters
21 | **string literal delimited by double or single quote characters when a string
22 | literal delimited by the other has already been found**. It will only raise this
23 | warning if the `quotmark` option is set to `true`. In the following example we
24 | attempt to assign string literals to the variables `x` and `y`:
25 |
26 |
31 | ```javascript
32 | /*jshint quotmark: true */
33 | var x = "My String",
34 | y = 'Another string';
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **lack of consistency**. Your code will run
40 | fine if you do not fix this error, but it demonstrates a lack of care. There is
41 | no difference in JavaScript between single and double quotes. This is made clear
42 | by the grammar for string literals ([ES5 §7.8.4][es5-7.8.4]):
43 |
44 | > *StringLiteral* ::
45 | > `"` *DoubleStringCharacters*opt `"`
46 | > `'` *SingleStringCharacters*opt `'`
47 |
48 | The only difference is that *DoubleStringCharacters* cannot contain another
49 | double quote, and *SingleStringCharacters* cannot contain a single quote (as
50 | that would terminate the string literal). However, it would usually be frowned
51 | upon to mix both types of quote within one program (there are obvious
52 | exceptions, such as nested quotes). You can easily resolve this issue by
53 | sticking to one type, and you should consider setting the `quotmark` option to
54 | either `double` or `single` to enforce your preference:
55 |
56 |
61 | ```javascript
62 | /*jshint quotmark: double */
63 | var x = "My String",
64 | y = "Another string";
65 | ```
66 |
67 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
68 | [special option syntax][jshintopts]. The identifier of this warning is **W110**.
69 | This means you can tell JSHint to not issue this warning with the `/*jshint
70 | -W110 */` directive. You can also set the `quotmark` option to `false`.
71 |
72 | [es5-7.8.4]: http://es5.github.io/#x7.8.4
73 | [jshintopts]: http://jshint.com/docs/#options
74 |
--------------------------------------------------------------------------------
/message-articles/move-parens.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### When do I get this error?
18 |
19 | The "Move the invocation into the parens that contain the function" error is
20 | thrown when JSLint and ESLint encounter **an immediately invoked function
21 | expression in which the invoking parentheses appear outside the wrapping
22 | parentheses**. In the following example we assign the return value of the
23 | anonymous function to the variable `x`:
24 |
25 |
30 | ```javascript
31 | var x = (function () {
32 | "use strict";
33 | return {
34 | y: 1
35 | };
36 | })();
37 | ```
38 |
39 | ### Why do I get this error?
40 |
41 | This error is raised to highlight a **lack of convention**. Your code will run
42 | fine if you do not fix this error, but it may be confusing to others. However,
43 | this particular error gives rise to debate over which position for the invoking
44 | parentheses should actually be the convention. If you are using JSLint, then
45 | your convention should be the one suggested.
46 |
47 | The argument for moving the parentheses is that it makes the code easier to
48 | understand. It may not be immediately obvious that the parentheses are intended
49 | to invoke the function if they are outside the wrapping pair. By moving them
50 | inside, they immediately follow the function statement and may therefore be more
51 | easily associated with it. To fix this error, simply move the pair of invoking
52 | parentheses inside the pair that wrap the function itself:
53 |
54 |
59 | ```javascript
60 | var x = (function () {
61 | "use strict";
62 | return {
63 | y: 1
64 | };
65 | }());
66 | ```
67 |
68 | If you're using ESLint you are able to configure the convention that you prefer.
69 | The `wrap-iife` option will accept a string, `"inside"` or `"outside"`, that
70 | will enforce a particular position (for some strange reason the "inside" option
71 | appears to force the invoking parentheses to appear *outside* of the wrapping
72 | ones, and vice versa):
73 |
74 |
79 | ```javascript
80 | /*eslint wrap-iife: [1, "outside"] */
81 | var x = (function () {
82 | "use strict";
83 | return {
84 | y: 1
85 | };
86 | }());
87 | ```
88 |
--------------------------------------------------------------------------------
/message-articles/move-var.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Move 'var' declarations to the top of the function" error is thrown when
19 | JSLint encounters **a variable declaration in a `for` or `for-in` statement
20 | initialiser**. Here's an example in which we have a simple `for` loop that
21 | declares a variable:
22 |
23 |
28 | ```javascript
29 | /*jslint plusplus: true */
30 | function demo(arr, callback) {
31 | "use strict";
32 | for (var i = 0; i < arr.length; i++) {
33 | callback(a[i]);
34 | }
35 | }
36 | ```
37 |
38 | ### Why do I get this error?
39 |
40 | This error is raised to highlight a possible **lack of convention** and a
41 | possible **misunderstanding of the language**. Your code will most likely work
42 | as expected if you do not resolve this issue, but you may have misunderstood how
43 | JavaScript handles variable declarations.
44 |
45 | All declarations are hoisted to the top of the scope in which they appear.
46 | Variables in JavaScript have function scope, not block scope. In many other
47 | languages, the variable `i` in the above example would be scoped to the `for`
48 | loop body and would not be accessible to the containing scope. In JavaScript
49 | this is not the case and the variable is actually accessible in the containing
50 | scope, although it won't have a value until the loop initialiser has been
51 | executed.
52 |
53 | To fix this issue, simply move the variable declaration out of the loop
54 | initialiser. This has the advantage of making the code read the way it is
55 | actually interpreted:
56 |
57 |
62 | ```javascript
63 | /*jslint plusplus: true */
64 | function demo(arr, callback) {
65 | "use strict";
66 | var i;
67 | for (i = 0; i < arr.length; i++) {
68 | callback(arr[i]);
69 | }
70 | }
71 | ```
72 |
73 | This approach also prevents you from redeclaring `i` in every loop within a
74 | function. You can simply reuse the reference to the `i` declared at the top of
75 | the function. In this example we have two loops using the same variable. When
76 | the first loop completes the value of `i` will be equal to `arr.length - 1`.
77 | When the second loop is executed `i` is reset to `0`:
78 |
79 |
84 | ```javascript
85 | /*jslint plusplus: true */
86 | function demo(arr, arr2, callback) {
87 | "use strict";
88 | var i;
89 | for (i = 0; i < arr.length; i++) {
90 | callback(arr[i]);
91 | }
92 | for (i = 0; i < arr2.length; i++) {
93 | callback(arr2[i]);
94 | }
95 | }
96 | ```
97 |
--------------------------------------------------------------------------------
/message-articles/nested-comment.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Nested comment" error is thrown when JSLint encounters **the character sequence `/*` inside a multiline comment**. Here's an example:
19 |
20 |
25 | ```javascript
26 | /* This is a multiline comment.
27 | /* It's valid JavaScript,
28 | but JSLint doesn't like it */
29 | ```
30 |
31 | ### Why do I get this error?
32 |
33 | This error is raised to highlight a **potentially dangerous piece of code**.
34 | While it is valid to include the `/*` sequence in a multiline comment, it is not
35 | valid to include `*/`. If you were to do so, everything following the first `*/`
36 | would be parsed as if it is not part of the comment. Here's an example (notice
37 | the syntax highlighting which demonstrates the error):
38 |
39 |
44 | ```javascript
45 | /* This is a multiline comment.
46 | /* It's valid JavaScript, */
47 | but JSLint doesn't like it */
48 | ```
49 |
50 | You can resolve this issue by simply removing `/*` character sequences from multiline comments:
51 |
52 |
57 | ```javascript
58 | /* This is a multiline comment.
59 | It's valid JavaScript,
60 | but JSLint doesn't like it */
61 | ```
62 |
--------------------------------------------------------------------------------
/message-articles/new-side-effects.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Do not use 'new' for side effects" error is thrown when JSLint, JSHint or
23 | ESLint encounters a **function invocation preceded by the new operator when not
24 | part of an assignment or comparison expression**. JSHint will only issue this
25 | warning if the `nonew` option is set to `true`. In the following example we
26 | call the built-in Date function as a constructor but don't assign the returned
27 | instance to anything:
28 |
29 |
37 | ```javascript
38 | /*jshint nonew: true */
39 | new Date();
40 | ```
41 |
42 | ### Why do I get this error?
43 |
44 | This error is raised to highlight a a **lack of convention**. While the code is
45 | perfectly valid it contravenes best practice, and in the case of the example
46 | above it indicates completely pointless code.
47 |
48 | By not assigning the return value of a constructor to something you will lose
49 | the reference to that instance. Generally, by constructing an instance you would
50 | want to keep that reference, whether to use again later or for "internal" use as
51 | part of a comparison. What's the point of constructing something you are going
52 | to throw away as soon as it's been created?
53 |
54 | If you have a constructor function that performs work beyond simply setting up
55 | an instance, and you are calling that constructor just for these "side effects",
56 | consider reworking your code to allow you to call the function normally, without
57 | the new operator. In the following simple example the side effect of calling the
58 | constructor is the incrementation of a variable:
59 |
60 |
65 | ```js
66 | /*jshint nonew: true */
67 | var counter = 0;
68 |
69 | function Person(name) {
70 | "use strict";
71 | this.name = name;
72 | counter += 1;
73 | }
74 |
75 | var me = new Person("James");
76 | new Person(); // Increments 'counter' as a side-effect
77 | ```
78 |
79 | In the above example we create two instances of `Person` but only keep the
80 | reference to one. The second call is simply there for the side effect of
81 | incrementing the counter. This example could be reworked to increment the
82 | counter without calling the constructor:
83 |
84 |
89 | ```js
90 | /*jshint nonew: true */
91 | var counter = 0;
92 |
93 | function Person(name) {
94 | "use strict";
95 | this.name = name;
96 | counter += 1;
97 | }
98 |
99 | var me = new Person("James");
100 | counter += 1; // Don't use the constructor
101 | ```
102 |
103 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
104 | [special option syntax][jshintopts]. The identifier of this warning is **W031**.
105 | This means you can tell JSHint to not issue this warning with the `/*jshint
106 | -W031 */` directive.
107 |
108 | In ESLint the rule that generates this warning is named `no-new`. You can
109 | disable it by setting it to `0`, or enable it by setting it to `1`.
110 |
111 | [jshintopts]: http://jshint.com/docs/#options
112 | [es5-12.6.4]: http://es5.github.io/#x12.6.4
113 |
--------------------------------------------------------------------------------
/message-articles/not-a-function.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "'{a}' is not a function" error is thrown when JSLint, JSHint or ESLint
23 | encounters **an attempt to invoke the `Math` object as a function**. JSLint and
24 | ESLint (but not JSHint) will also raise this warning when they encounter **an
25 | attempt to invoke the `JSON` object as a function**. Here's an example:
26 |
27 |
32 | ```javascript
33 | var x = Math(),
34 | y = JSON();
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight what is most likely a **misunderstanding of
40 | the language**. The `Math` property of the global object is described in the
41 | specification as follows ([ES5 §15.8][es5-15.8]):
42 |
43 | > The Math object does not have a [[Construct]] internal property; it is not
44 | > possible to use the Math object as a constructor with the `new` operator.
45 | >
46 | > The Math object does not have a [[Call]] internal property; it is not possible
47 | > to invoke the Math object as a function.
48 |
49 | This makes it very clear that the Math object cannot be invoked in the way you
50 | normally call a function or a constructor. Instead it is simply an object with a
51 | set of properties, some of which are functions.
52 |
53 | The specification makes the same note about the `JSON` object ([ES5
54 | §15.12][es5-15.12]):
55 |
56 | > The JSON object does not have a [[Construct]] internal property; it is not
57 | > possible to use the JSON object as a constructor with the `new` operator.
58 | >
59 | > The JSON object does not have a [[Call]] internal property; it is not possible
60 | > to invoke the JSON object as a function.
61 |
62 | Both `Math` and `JSON` objects expose a number of properties that can be
63 | accessed in the normal way. If you're receiving this error the chances are you
64 | intended to invoke one of the function properties instead of the object itself.
65 | For example:
66 |
67 |
72 | ```javascript
73 | var x = Math.random(),
74 | y = JSON.stringify({});
75 | ```
76 |
77 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
78 | [special option syntax][jshintopts]. The identifier of this warning is **W063**.
79 | This means you can tell JSHint to not issue this warning with the `/*jshint
80 | -W063 */` directive.
81 |
82 | In ESLint the rule that generates this warning is named `no-obj-calls`. You can
83 | disable it by setting it to `0`, or enable it by setting it to `1`.
84 |
85 | [es5-15.8]: http://es5.github.io/#x15.8
86 | [es5-15.12]: http://es5.github.io/#x15.12
87 | [jshintopts]: http://jshint.com/docs/#options
88 |
--------------------------------------------------------------------------------
/message-articles/overriding-constant.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Attempting to override '{a}' which is a constant" error is thrown when
21 | JSHint encounters an **assignment expression with an identifer that has been
22 | declared in a constant variable statement**. In the following example we declare
23 | a constant `MY_CONST` and assign a value to it, and then attempt to change its
24 | value:
25 |
26 |
31 | ```javascript
32 | /*jshint esnext: true */
33 | const MY_CONST = 10;
34 | MY_CONST = 20;
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **fatal JavaScript type error**. Your code
40 | will fail to run if you do not resolve this error. Mozilla Developer Network
41 | offers the following note:
42 |
43 | > The value of a constant cannot change through re-assignment, and a constant
44 | > cannot be re-declared.
45 |
46 | You can fix this issue by removing any assignments to constants declared with
47 | the `const` keyword:
48 |
49 |
54 | ```javascript
55 | /*jshint esnext: true */
56 | const MY_CONST = 10;
57 | ```
58 |
59 | However, since browser support for the `const` statement is limited and most
60 | implementations currently differ significantly from the upcoming ECMAScript 6
61 | specification, it's recommended that you don't use it all, and simply use the
62 | `var` statement instead. A common convention to indicate a variable with a value
63 | that shouldn't change is to give that variable an identifier made up of
64 | uppercase characters, as has been done in the previous examples:
65 |
66 |
71 | ```javascript
72 | /*jshint esnext: true */
73 | var MY_CONST = 10; // A fake constant
74 | ```
75 |
76 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
77 | [special option syntax][jshintopts]. Since this message relates to a fatal
78 | syntax error you cannot disable it.
79 |
80 | [jshintopts]: http://jshint.com/docs/#options
81 |
--------------------------------------------------------------------------------
/message-articles/redefinition-of-native.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Redefinition of '{a}'" error is thrown when JSHint or ESLint encounters a
22 | **variable declaration with an identifier that is the same as that of a built-in
23 | native object**. In the following example we attempt to declare a variable with
24 | the identifier `String`:
25 |
26 |
31 | ```javascript
32 | var String = "My String";
33 | ```
34 |
35 | This warning will often appear alongside the related "[Read only][ro]" message
36 | so you may find it useful to read the explanations of that one too.
37 |
38 | ### Why do I get this error?
39 |
40 | This error is raised to highlight a **potentially dangerous piece of code**.
41 | Your code may run fine if you do not fix this error, but it will be confusing to
42 | others, especially at first glance to someone quickly searching through your
43 | script, and it will be likely to break third party scripts.
44 |
45 | It is perfectly valid to reassign (and thereby override) any of the native
46 | built-in functions, but there are limited use cases for it. JSHint forbids this
47 | practice completely and does not provide an option to allow it. The list of
48 | objects to which this rule applies is as follows. Each item concerns all
49 | versions of JSHint and ESLint unless noted otherwise:
50 |
51 | - `Array`
52 | - `Boolean`
53 | - `Date`
54 | - `decodeURI`
55 | - `decodeURIComponent`
56 | - `encodeURI`
57 | - `encodeURIComponent`
58 | - `Error`
59 | - `eval`
60 | - `EvalError`
61 | - `Function`
62 | - `hasOwnProperty` (JSHint only)
63 | - `Infinity` (ESLint only)
64 | - `isFinite`
65 | - `isNaN`
66 | - `JSON`
67 | - `Map` (added to JSHint in version r11)
68 | - `Math`
69 | - `NaN` (added to JSHint in version r11, not in ESLint)
70 | - `Number`
71 | - `Object`
72 | - `parseInt`
73 | - `parseFloat`
74 | - `RangeError`
75 | - `ReferenceError`
76 | - `RegExp`
77 | - `Set` (added to JSHint in version r11)
78 | - `String`
79 | - `SyntaxError`
80 | - `TypeError`
81 | - `undefined` (ESLint only)
82 | - `URIError`
83 | - `WeakMap` (added to JSHint in version r11)
84 | - `WeakSet` (added to JSHint in version r11)
85 |
86 |
87 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
88 | [special option syntax][jshintopts]. The identifier of this warning is **W079**.
89 | This means you can tell JSHint to not issue this warning with the `/*jshint
90 | -W079 */` directive.
91 |
92 | In ESLint the rule that generates this warning is named `no-native-reassign`.
93 | You can disable it by setting it to `0`, or enable it by setting it to `1`.
94 |
95 | [ro]: /read-only
96 | [jshintopts]: http://jshint.com/docs/#options
97 |
--------------------------------------------------------------------------------
/message-articles/regex-division.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### History
21 |
22 | This warning was introduced in the original version of JSLint and existed in the
23 | same form in JSHint until version 1.0.0 when it was removed. ESLint has always
24 | issued the same warning.
25 |
26 | ### When do I get this error?
27 |
28 | The "A regular expression literal can be confused with '/='" error is thrown
29 | when JSLint, JSHint (prior to version 1.0.0) or ESLint encounters **a regular
30 | expression literal that begins with the = character**. In the following example
31 | we attempt to assign a regular expression literal to match the string `"=1"` to
32 | the variable `x`:
33 |
34 |
39 | ```javascript
40 | var regex = /=1/;
41 | ```
42 |
43 | ### Why do I get this error?
44 |
45 | This error is raised to highlight a **potentially confusing piece of code**.
46 | Your code will run fine if you do not fix this error, but it may be confusing to
47 | others, especially at first glance to someone quickly searching through your
48 | script.
49 |
50 | The `/` character is ambiguous in JavaScript. It can either signify the start or
51 | end of a regular expression literal, as it does in the example above, or it can
52 | be interpreted as the division operator. Like most of the arithmetic operators,
53 | the division operator can be combined with the assignment operator to produce a
54 | shorthand:
55 |
56 |
61 | ```js
62 | var x = 10;
63 | x /= 5; // Shorthand division-assignment operator
64 | ```
65 |
66 | This ambiguity is not a problem because the parser should always be able to
67 | differentiate between the two uses. However, you can see why the regular
68 | expression example at the top of this page could cause initial confusion.
69 |
70 | To solve this issue, you can simply escape the `=` character in the regular
71 | expression. This will behave in exactly the same way but since the `=` character
72 | is no longer the first, the error is not raised:
73 |
74 |
79 | ```javascript
80 | var regex = /\=1/;
81 | ```
82 |
83 | Alternatively, you can use the RegExp constructor, which removes the need for
84 | the ambiguous delimiting `/` characters:
85 |
86 |
91 | ```javascript
92 | var regex = new RegExp("=1");
93 | ```
94 |
95 | In ESLint the rule that generates this warning is named `no-div-regex`. You can
96 | disable it by setting it to `0`, or enable it by setting it to `1`.
97 |
--------------------------------------------------------------------------------
/message-articles/regex-spaces.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "Spaces are hard to count. Use {a}" error is thrown when JSLint, ESLint or
21 | JSHint (prior to version 1.0.0) encounters a **regular expression literal
22 | containing two or more consecutive space characters**. In the following example
23 | we define a regular expression that will match the string
24 | "three spaces" (there are three spaces between the two words):
25 |
26 |
31 | ```javascript
32 | var regex = /^three spaces$/;
33 | ```
34 |
35 | ### Why do I get this error?
36 |
37 | This error is raised to highlight a **potentially confusing piece of code**.
38 | Your script will run without error if you do not change it, but it could be
39 | confusing to other developers, especially at first glance. Anyone who wants to
40 | understand exactly what the regular expression should match will have to stop
41 | and count the number of spaces. This is unnecessary, since there is an
42 | alternative syntax that makes it much clearer. To fix this error, simply use the
43 | repetition operator:
44 |
45 |
50 | ```javascript
51 | var regex = /^three {3}spaces$/;
52 | ```
53 |
54 | Alternatively, if you have a valid reason to use consecutive literal space
55 | characters and don't want to use the repetition operator, you can modify your
56 | code to use the `RegExp` constructor rather than a regular expression literal,
57 | since JSLint, JSHint and ESLint will only raise this error for literals:
58 |
59 |
64 | ```javascript
65 | var regex = new RegExp("^three spaces$");
66 | ```
67 |
68 | In ESLint the rule that generates this warning is named `no-regex-spaces`. You
69 | can disable it by setting it to `0`, or enable it by setting it to `1`.
70 |
--------------------------------------------------------------------------------
/message-articles/return-conditional.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### When do I get this error?
22 |
23 | The "Did you mean to return a conditional instead of an assignment?" error, and
24 | the alternative "Return statement should not contain assignment", is thrown when
25 | JSHint or ESLint encounters a **return statement containing an assignment
26 | expression**. In the following example we attempt to assign the result of an
27 | operation to `result` and also return the result of that assignment:
28 |
29 |
34 | ```javascript
35 | var result;
36 | function multiply(a, b) {
37 | "use strict";
38 | return result = a * b;
39 | }
40 | ```
41 |
42 | Since May 2013 JSLint has used the more generic "[Unexpected assignment
43 | expression][unexpass]" warning in the same situation.
44 |
45 | ### Why do I get this error?
46 |
47 | This error is raised to highlight a **lack of convention**. Your code may run
48 | fine if you do not fix this error, but it will be confusing to others,
49 | especially at first glance to someone quickly searching through your script.
50 |
51 | The above example works because the assignment expression, `result = a * b`,
52 | returns the resultant value of `result`. Since in a `return` statement the
53 | expression is evaluated and its result is returned from the function we end up
54 | with the value we expect. You can resolve this error by splitting the logic out
55 | into two distinct steps which makes the code much more readable:
56 |
57 |
62 | ```javascript
63 | var result;
64 | function multiply(a, b) {
65 | "use strict";
66 | result = a * b;
67 | return result;
68 | }
69 | ```
70 |
71 | If you didn't mean to return the result of an assignment and are receiving this
72 | error then the chances are you actually wanted to return a boolean value. This
73 | is why JSHint asks if you meant to return a conditional. If that's the case,
74 | make sure the expression is conditional by using `===` instead of `=`:
75 |
76 |
81 | ```javascript
82 | var result;
83 | function multiply(a, b) {
84 | "use strict";
85 | return result === a * b;
86 | }
87 | ```
88 |
89 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
90 | [special option syntax][jshintopts]. The identifier of this warning is **W093**.
91 | This means you can tell JSHint to not issue this warning with the `/*jshint
92 | -W093 */` directive.
93 |
94 | In ESLint the rule that generates this warning is named `no-return-assign`. You
95 | can disable it by setting it to `0`, or enable it by setting it to `1`.
96 |
97 | [unexpass]: /unexpected-assignment-expression
98 | [jshintopts]: http://jshint.com/docs/#options
99 |
--------------------------------------------------------------------------------
/message-articles/stopping.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Stopping. ({a}% scanned)" error is thrown when JSLint or JSHint encounters
22 | **a JavaScript syntax error** and cannot continue to reliably parse the program.
23 | JSHint will only raise this error if the `passfail` option is set to `true`. In
24 | the following example we have half a variable statement which is invalid and
25 | cannot be parsed as a complete JavaScript program:
26 |
27 |
32 | ```javascript
33 | /*jshint passfail: true */
34 | var
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **fatal JavaScript syntax error** and the
40 | fact that **the parser cannot reliably finish parsing your program**. Your code
41 | will not run unless you fix this error. The exact cause will depend on your
42 | program, but other errors are usually raised along side this one that should
43 | guide you to the problem with your code. In our example, the variable statement
44 | is missing an identifier:
45 |
46 |
51 | ```javascript
52 | /*jshint passfail: true */
53 | var a;
54 | ```
55 |
56 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
57 | [special option syntax][jshintopts]. Since this message relates to a fatal
58 | syntax error you cannot disable it.
59 |
60 | [jshintopts]: http://jshint.com/docs/#options
61 |
--------------------------------------------------------------------------------
/message-articles/subexpression-parens.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "The '&&' subexpressions should be wrapped in parens" error is thrown when
19 | JSLint encounters **an expression containing both logical 'or' and logical 'and'
20 | operators**. The following example function will return `true` if the `a`
21 | argument is truthy or if both the `b` and `c` arguments are truthy:
22 |
23 |
28 | ```javascript
29 | function test(a, b, c) {
30 | "use strict";
31 | if (a || b && c) {
32 | return true;
33 | }
34 | return false;
35 | }
36 | ```
37 |
38 | ### Why do I get this error?
39 |
40 | This error is raised to help **improve the readability of your code**. The
41 | precedence of operators may be confusing to others (and to you, if you revisit
42 | your code some time in the future). However, the code above is valid and will
43 | work as expected.
44 |
45 | The logical 'and' operator has a [higher precedence][ops] than the 'or'
46 | operator. This is the reason the above example was described as returning `true`
47 | when `a` is truthy or when both `b` and `c` are truthy. If the precedence was
48 | reversed then the function would return `true` when `c` is truthy and either `a`
49 | or `b` is truthy.
50 |
51 | To avoid potential confusion around operator precedence JSLint prefers that the
52 | order of operation be explicity defined by parentheses:
53 |
54 |
59 | ```javascript
60 | function test(a, b, c) {
61 | "use strict";
62 | if (a || (b && c)) {
63 | return true;
64 | }
65 | return false;
66 | }
67 | ```
68 |
69 | This example will behave in exactly the same way as the first but JSLint is
70 | happy because the order in which parts of the expression are evaluated is
71 | clearer.
72 |
73 | [ops]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence
74 |
--------------------------------------------------------------------------------
/message-articles/todo-comment.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Unexpected TODO comment" error is thrown when JSLint encounters an attempt
19 | to **a comment in which the first word is `TODO`**. The regular expression used by JSLint to determine whether a comment is a "todo" comment or not is `/^\W*to\s*do(?:\W|$)/i`. Here's a few examples:
20 |
21 |
26 | ```javascript
27 | // TODO: Finish writing about JSLint errors
28 | // todo
29 | // to do
30 | // ... to do
31 | ```
32 |
33 | ### Why do I get this error?
34 |
35 | This error is raised to highlight a **lack of convention**. Comments that start
36 | with the word `TODO` are commonly used to mark unfinished parts of code. JSLint
37 | takes the safe approach and assumes that your code is not production-ready if it
38 | contains such comments. If you are happy with "todo" comments being in your
39 | code, you can pass the `todo` option to JSLint to tell it to ignore them:
40 |
41 |
46 | ```javascript
47 | /*jslint todo: true */
48 |
49 | // TODO: Finish writing about JSLint errors
50 | // todo
51 | // to do
52 | // ... to do
53 | ```
54 |
--------------------------------------------------------------------------------
/message-articles/trailing-decimal.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### History
23 |
24 | This warning has existed in two forms across the three main linters. It was
25 | introduced in the original version of JSLint and has remained in all three tools
26 | ever since.
27 |
28 | - In JSLint versions dated before May 2013 the warning given is *"A trailing
29 | decimal point can be confused with a dot: '{a}'"*
30 |
31 | - In JSLint version dated May 2013 and later this message has been replaced
32 | with the more generic *"Unexpected '{a}'"*
33 |
34 | - In JSHint and ESLint the message has always been *"A trailing decimal point
35 | can be confused with a dot: '{a}'"*
36 |
37 | The situations that produce the warning have not changed despite changes to the
38 | text of the warning itself.
39 |
40 | ### When do I get this error?
41 |
42 | The "A trailing decimal point can be confused with a dot" error is thrown when
43 | JSLint, JSHint and ESLint encounter **a numeric literal followed by a `.` token
44 | which itself is not followed by a decimal integer literal**. Here's an example
45 | in which we attempt to assign the value `5.0` to the variable `x`:
46 |
47 |
53 | ```javascript
54 | var x = 5.;
55 | ```
56 |
57 | ### Why do I get this error?
58 |
59 | This error is raised to highlight a **potentially confusing piece of code**.
60 | Your code will run without error if you do not address this issue but it could
61 | be confusing to other developers. The ECMAScript standard states that it is
62 | syntactically valid for a numeric literal to end with a . character ([ES5
63 | Annex 1][es5-a1]):
64 |
65 | > *DecimalLiteral* ::
66 | > *DecimalIntegerLiteral* `.`
67 | > *DecimalDigits*opt *ExponentPart*opt
68 | > `.` *DecimalDigits* *ExponentPart*opt
69 | > *DecimalIntegerLiteral* *ExponentPart*opt
70 |
71 | The first production in the grammar quoted above shows the situation we
72 | encounter in the example at the top of this page. However, since the `.`
73 | character is ambiguous (it's also commonly seen in use as a "member operator",
74 | to access a property of an object), JSLint, JSHint and ESLint prefer the
75 | explicit third production from the above grammar, just to make your code easier
76 | to understand. Therefore to fix this error you can simply remove the `.`:
77 |
78 |
84 | ```javascript
85 | var x = 5;
86 | ```
87 |
88 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
89 | [special option syntax][jshintopts]. The identifier of this warning is **W047**.
90 | This means you can tell JSHint to not issue this warning with the `/*jshint
91 | -W047 */` directive.
92 |
93 | In ESLint the rule that generates this warning is named `no-floating-decimal`.
94 | You can disable it by setting it to `0`, or enable it by setting it to `1`.
95 |
96 | [es5-11.9.6]: http://es5.github.com/#x11.9.6
97 | [es5-11.9.3]: http://es5.github.com/#x11.9.3
98 | [es5-15.1.2.4]: http://es5.github.com/#x15.1.2.4
99 | [jshintopts]: http://jshint.com/docs/#options
100 |
--------------------------------------------------------------------------------
/message-articles/type-confusion.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Type confusion: {a} and {b}" error is thrown when JSLint (versions dated
19 | between June 2011 and July 2011) encounters **an attempt to change the type of
20 | data assigned to a variable**. In the following example we first assign a number
21 | to `x` and then attempt to assign a string:
22 |
23 |
29 | ```javascript
30 | var x = 1; // number
31 | x = "str"; // string
32 | ```
33 |
34 | ### Why do I get this error?
35 |
36 | This error is raised to highlight a **potentially confusing piece of code**. When you assign a value to a variable, it is common to expect the data type of that value to remain consistent throughout a program. However, in JavaScript you are free to assign values of any type to any variable, regardless of its current value, so there is no language-based reason for this warning.
37 |
38 | In fact, the code within JSLint that leads to this warning lived such a short life in the wild that it was quite likely just an experiment, never really intended for public use. Unfortunately, it appears various IDEs or editors with built-in JavaScript linting functionality are stuck using an old version of JSLint in which type checking was available.
39 |
40 | To resolve the issue (assuming you want to retain the ability to assign values of different types) you should upgrade to a more recent version of JSLint. If that is not possible, you can set the `confusion` option to `true`:
41 |
42 |
48 | ```javascript
49 | /*jslint confusion: true */
50 | var x = 1; // number
51 | x = "str"; // string
52 | ```
53 |
--------------------------------------------------------------------------------
/message-articles/unclosed-comment.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Unclosed comment" error is thrown when JSLint or JSHint encounters **a
22 | multiline comment that does not end with the character sequence `*/`**. Here's
23 | an example:
24 |
25 |
30 | ```javascript
31 | /* This is a comment
32 | * but I forgot to
33 | * close it.
34 | ```
35 |
36 | ### Why do I get this error?
37 |
38 | This error is raised to highlight a **fatal JavaScript syntax error**. Your code
39 | will not run unless you fix this issue. The ECMAScript 5 specification lists the
40 | following grammar for multiline comments ([ES5 §7.4][es5-7.4]):
41 |
42 | > *MultiLineComment* ::
43 | > `/*` *MultiLineCommentChars*opt `*/`
44 |
45 | We can see from the above quote that multiline comments must end with the `*/`
46 | characters. If you have an unclosed multiline comment a syntax error will be
47 | thrown when the interpreter reaches the end of the file. Here's the above
48 | snippet once more, except we've closed the comment this time:
49 |
50 |
55 | ```javascript
56 | /* This is a comment
57 | * but I remembered to
58 | * close it. */
59 | ```
60 |
61 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
62 | [special option syntax][jshintopts]. Since this message relates to a fatal
63 | syntax error you cannot disable it.
64 |
65 | #### ~~JSHint bug alert~~
66 |
67 | **Fixed as of JSHint 1.0.0**. As you may have noticed if you have switched one
68 | of the examples above to use a pre-1.0.0 version of JSHint instead of JSLint, a
69 | large number of the same message appear to get generated for the first unclosed
70 | comment, to the point where the parser gives up and tells you that there are too
71 | many errors.
72 |
73 | [es5-7.4]: http://es5.github.com/#x7.4
74 | [jshintopts]: http://jshint.com/docs/#options
75 |
--------------------------------------------------------------------------------
/message-articles/unclosed-mega-literal.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### When do I get this error?
22 |
23 | The "Unclosed mega literal" error is thrown when JSLint encounters an **unclosed
24 | template string literal**. JSHint raises the "Unclosed template literal" error
25 | in the same situation. Note that because [template string literals][tsl] are an
26 | ES2015 (ES6) feature this error should only appear when linting ES2015 code with
27 | the appropriate option set in the linter.
28 |
29 | In the following example we attempt to assign an unclosed template string
30 | literal to `a`:
31 |
32 | ```javascript
33 | /*jslint es6: true */
34 | let x = `unclosed;
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **fatal JavaScript syntax error**. Your code
40 | will not run unless you fix this issue. The ECMAScript grammar states that any
41 | template literal must be closed by the backtick character ([ES2015 §11.8.68][es6-11.8.6]):
42 |
43 | > *Template* ::
44 | > *NoSubstitutionTemplate*
45 | > *TemplateHead*
46 | > *NoSubstitutionTemplate* ::
47 | > \` *TemplateCharacters*opt \`
48 |
49 | The grammar for *NoSubstitutionTemplate* is straightforward and shows the
50 | necessary backticks. The second production is far more complicated and beyond
51 | the scope of this article but does also require an opening and closing backtick.
52 |
53 | To fix the error, simply close any unclosed template strings:
54 |
55 | ```javascript
56 | /*jslint es6: true */
57 | let x = `unclosed`;
58 | ```
59 |
60 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
61 | [special option syntax][jshintopts]. Since this message relates to a fatal
62 | syntax error you cannot disable it.
63 |
64 | [tsl]: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/template_strings
65 | [es6-11.8.6]: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-template-literal-lexical-components
66 | [jshintopts]: http://jshint.com/docs/#options
67 |
--------------------------------------------------------------------------------
/message-articles/unclosed-regex.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Unclosed regular expression" error is thrown when JSLint or JSHint encounters **a regular expression literal with no closing `/` character**. Here's an example:
22 |
23 |
28 | ```javascript
29 | var regex = /^unclosed$;
30 | ```
31 |
32 | ### Why do I get this error?
33 |
34 | This error is raised to highlight a **fatal JavaScript syntax error**. Your code
35 | will not run unless you fix this issue. The ECMAScript 5 specification lists the
36 | following grammar for regular expression literals ([ES5
37 | §7.8.5][es5-7.8.5]):
38 |
39 | > *RegularExpressionLiteral* ::
40 | > `/` *RegularExpressionBody* `/`
41 | > *RegularExpressionFlags*
42 |
43 | This production makes it clear that regular expression literal bodies must be
44 | terminated by a `/` character. Not doing so will always cause a syntax error. To
45 | fix this issue, simply close the regular expression in question:
46 |
47 |
52 | ```javascript
53 | var regex = /^closed$/;
54 | ```
55 |
56 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
57 | [special option syntax][jshintopts]. Since this message relates to a fatal
58 | syntax error you cannot disable it.
59 |
60 | [es5-7.8.5]: http://es5.github.com/#x7.8.5
61 | [jshintopts]: http://jshint.com/docs/#options
62 |
--------------------------------------------------------------------------------
/message-articles/unclosed-string.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Unclosed string" error is thrown when JSLint or JSHint encounters a **a
22 | string that is not closed before the next line break or the end of the
23 | program**. There are numerous situations that could cause this. In this first
24 | example, we accidentally forget to close our string:
25 |
26 |
31 | ```javascript
32 | var myString = "my string,
33 | myNumber = 10;
34 | ```
35 |
36 | In the next example, we want our string to include a backslash character. The
37 | string appears to be closed but actually isn't, due to the backslash character
38 | escaping the closing quote:
39 |
40 |
45 | ```javascript
46 | var myString = "my string\",
47 | myNumber = 10;
48 | ```
49 |
50 | And this final example, which makes use of the multiline strings allowed by
51 | ECMAScript 5, features a string that has not closed by the end of the program
52 | (the previous two examples failed at the first line break):
53 |
54 |
59 | ```javascript
60 | var myString = "my multiline \
61 | string
62 | ```
63 |
64 | ### Why do I get this error?
65 |
66 | This error is raised to highlight a **fatal JavaScript syntax error**. Your code
67 | will not run unless you fix this issue. The ECMAScript grammar states that any
68 | string literal must be closed by the same character (either `"` or `'`) that
69 | opened it ([ES5 §7.8.4][es5-7.8.4]):
70 |
71 | > *StringLiteral* ::
72 | > `"` *DoubleStringCharacters*opt `"`
73 | > `'` *SingleStringCharacters*opt `'`
74 |
75 | To fix the error, simply close any unclosed strings:
76 |
77 |
82 | ```javascript
83 | var myString = "my string",
84 | myNumber = 10;
85 | ```
86 |
87 | The second example above failed because the backslash character was escaping the
88 | closing quote, turning it into a literal character rather than a syntactic
89 | structure. To include a backslash in a string, you need to escape the backslash
90 | itself:
91 |
92 |
97 | ```javascript
98 | var myString = "my string\\",
99 | myNumber = 10;
100 | ```
101 |
102 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
103 | [special option syntax][jshintopts]. Since this message relates to a fatal
104 | syntax error you cannot disable it.
105 |
106 | [es5-7.8.4]: http://es5.github.com/#x7.8.4
107 | [jshintopts]: http://jshint.com/docs/#options
108 |
--------------------------------------------------------------------------------
/message-articles/unexpected-comment.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Unexpected comment" error is thrown when JSLint encounters a single-line or
19 | multi-line **comment in a JSON string**. It will only generate this error when
20 | in JSON mode (it enters JSON mode when the first character of the input is
21 | either `{` or `[`). In the following example we attempt to comment one of our
22 | JSON properties:
23 |
24 |
29 | ```javascript
30 | {
31 | "name": "James", // My first name
32 | "age": 24
33 | }
34 | ```
35 |
36 | ### Why do I get this error?
37 |
38 | This error is raised to highlight a **fatal syntax error**. The [JSON
39 | specification][json] does not provide any mechanism for comments. Attempting to
40 | deserialize the above example (using `JSON.parse` for example) will throw a
41 | syntax error. To solve this issue, simply remove any comments from your JSON:
42 |
43 |
48 | ```javascript
49 | {
50 | "name": "James",
51 | "age": 24
52 | }
53 | ```
54 |
55 | [json]: http://json.org/
56 |
--------------------------------------------------------------------------------
/message-articles/unexpected-get-param.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### History
21 |
22 | This warning has existed in two forms across the three main linters. It was
23 | introduced in the original version of JSLint and has remained (in a way) in all
24 | three tools ever since.
25 |
26 | - In JSLint and JSHint the warning given is "Unexpected parameter '{a}' in get
27 | {b} function"
28 |
29 | - In ESLint the message used is the more generic "Unexpected identifier"
30 |
31 | The situations that produce the warning have not changed despite changes to the
32 | text of the warning itself.
33 |
34 | ### When do I get this error?
35 |
36 | The "Unexpected parameter '{a}' in get {b} function" error, and the
37 | alternative "Unexpected identifier", is thrown when JSLint, JSHint or ESLint
38 | encounters **a named parameter in the signature of a property getter function**.
39 | In the following example we create an object x with a getter and setter. The
40 | getter will always return half of the set value:
41 |
42 |
47 | ```javascript
48 | var x = {
49 | actual: 10,
50 | get x (value) {
51 | "use strict";
52 | return this.actual / 2;
53 | },
54 | set x (value) {
55 | "use strict";
56 | this.actual = value;
57 | }
58 | };
59 | ```
60 |
61 | ### Why do I get this error?
62 |
63 | This error is raised to highlight a **completely pointless and potentially
64 | confusing piece of code**. Your code will run without error if you do not change
65 | it, but could be confusing to other developers and adds unnecessary bytes to the
66 | weight of your script. ECMAScript 5 added new syntax for object property getter
67 | and setter functions. The specification states the following in reference to
68 | getters ([ES5 §8.6.1][es5-8.6.1]):
69 |
70 | > The function’s [[Call]] internal method... is called with an empty arguments
71 | > list to return the property value each time a get access of the property is
72 | > performed.
73 |
74 | Since the runtime will never pass any arguments to the getter function, there is
75 | no need to provide any named parameters in the function signature. Simply remove
76 | them to fix the error:
77 |
78 |
83 | ```javascript
84 | var x = {
85 | actual: 10,
86 | get x () {
87 | "use strict";
88 | return this.actual / 2;
89 | },
90 | set x (value) {
91 | "use strict";
92 | this.actual = value;
93 | }
94 | };
95 | ```
96 |
97 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
98 | [special option syntax][jshintopts]. The identifier of this warning is **W076**.
99 | This means you can tell JSHint to not issue this warning with the `/*jshint
100 | -W076 */` directive.
101 |
102 | [es5-8.6.1]: http://es5.github.com/#x8.6.1
103 | [jshintopts]: http://jshint.com/docs/#options
104 |
--------------------------------------------------------------------------------
/message-articles/unexpected-increment.md:
--------------------------------------------------------------------------------
1 |
24 |
25 | ### History
26 |
27 | This warning has existed in two forms in JSLint and ESLint. It was introduced in
28 | the original version of JSLint and has remained in both tools since. It is not
29 | present in JSHint.
30 |
31 | - In JSLint the warning given is "Unexpected '++'" (or "Unexpected '--'")
32 |
33 | - In ESLint the message has always been "Unary operator '++' used" (or "Unary
34 | operator '--' used")
35 |
36 | The situations that produce the warning have not changed despite changes to the
37 | text of the warning itself.
38 |
39 | ### When do I get this error?
40 |
41 | The "Unexpected '++'" error, and the alternative "Unary operator '++' used", is
42 | thrown when JSLint or ESLint encounters a **use of the increment or decrement
43 | operators**. In ESLint the warning is only raised if the `no-plusplus` option is
44 | set to `1`. Here's an example:
45 |
46 |
54 | ```javascript
55 | var x = 1,
56 | y = 10;
57 |
58 | x++;
59 | y--;
60 | ```
61 |
62 | ### Why do I get this error?
63 |
64 | This error message is perhaps the most debated of all JSLint error messages. It
65 | exists solely to warn you that JSLint has encountered a **violation of a
66 | specific coding style**. The style in question is the style of the author of
67 | JSLint, Douglas Crockford. For his reasoning, you can read the [JSLint
68 | documentation][doc]:
69 |
70 | > The ++ (increment) and -- (decrement) operators have been known to contribute
71 | > to bad code by encouraging excessive trickiness. They are second only to
72 | > faulty architecture in enabling to viruses and other security menaces. Also,
73 | > preincrement/postincrement confusion can produce off-by-one errors that are
74 | > extremely difficult to diagnose.
75 |
76 | There are many JavaScript developers who disagree with that, but the fact
77 | remains, it's a rule in JSLint so you need a way to work around it. What JSLint
78 | would prefer you to do is use the normal addition and subtraction operators,
79 | which can be combined with the assignment operator for a slight decrease in
80 | length:
81 |
82 |
90 | ```javascript
91 | var x = 1,
92 | y = 10;
93 |
94 | x = x + 1; // or x += 1;
95 | y = y - 1; // or y -= 1;
96 | ```
97 |
98 | If you would prefer not to do that, and would rather stick with the normal
99 | increment and decrement operators, you can set the `plusplus` option to `true`
100 | to tell JSLint to allow them:
101 |
102 |
110 | ```javascript
111 | /*jslint plusplus: true */
112 | var x = 1,
113 | y = 10;
114 |
115 | x++;
116 | y--;
117 | ```
118 |
119 | In ESLint the rule that generates this warning is named `no-plusplus`. You
120 | can disable it by setting it to `0`, or enable it by setting it to `1`.
121 |
122 | [doc]: http://www.jslint.com/lint.html#inc
123 |
--------------------------------------------------------------------------------
/message-articles/unexpected-sync.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Unexpected sync method: '{a}'" error is thrown when JSLint (versions from
19 | March 2012 onwards) encounters an attempt to **access a property whose
20 | identifier ends with the character sequence `Sync`**. In the following Node.js
21 | example we attempt to get an array containing the names of files within a
22 | directory:
23 |
24 |
29 | ```javascript
30 | /*jslint node: true */
31 | var fs = require("fs"),
32 | files = fs.readdirSync("myDirectory");
33 | ```
34 |
35 | Note that although the error messages states "method", JSLint will actually
36 | raise this error for an attempt to access any property that fits the criteria,
37 | whether it's a method or not (it doesn't check to see if a pair of invoking
38 | parentheses follow the identifier).
39 |
40 | ### Why do I get this error?
41 |
42 | This error is raised to highlight a **lack of convention** and possible **bad
43 | practice**. Your code should run without problems if you don't change it, but
44 | it's likely there are better ways to acheive the same result.
45 |
46 | In Node.js in particular, there are many asynchronous methods that provide
47 | synchronous equivalents. For example, there is a [`readdir`][readdir] method
48 | that is the asynchronous version of the [`readdirSync`][readdirsync] method in
49 | our example above.
50 |
51 | In almost all situations it's preferrable to use the asynchronous method over
52 | the synchronous one. The reason is that synchronous methods will block execution
53 | until they have finished doing whatever they need to do. In the browser this can
54 | result in an apparently "frozen" page. To fix this issue, simply rework your
55 | code to use the asynchronous version of the method:
56 |
57 |
62 | ```javascript
63 | /*jslint node: true */
64 | var fs = require("fs");
65 |
66 | fs.readdir("myDirectory", function (err, files) {
67 | "use strict";
68 | if (!err) {
69 | console.log(files);
70 | }
71 | });
72 | ```
73 |
74 | Alternatively, if you have a real need to use synchronous methods, you can
75 | surpress this error by setting the `stupid` option to `true`. You can tell by
76 | the name of the option how Douglas Crockford, author of JSLint, feels about
77 | this:
78 |
79 |
84 | ```javascript
85 | /*jslint node: true, stupid: true */
86 | var fs = require("fs"),
87 | files = fs.readdirSync("myDirectory");
88 | ```
89 |
90 | [readdir]: http://nodejs.org/api/fs.html#fs_fs_readdir_path_callback
91 |
--------------------------------------------------------------------------------
/message-articles/unnecessary-else.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### History
20 |
21 | This warning has existed in two forms in JSLint and ESLint. It was
22 | introduced in the original version of JSLint and has remained in both tools
23 | ever since. It is not present in JSHint.
24 |
25 | - In JSLint versions dated later than April 2013 the warning given is
26 | "Unnecessary 'else' after disruption"
27 |
28 | - In older versions of JSLint and in all versions of ESLint the message used is
29 | "Unexpected 'else' after 'return'"
30 |
31 | The situations that produce the warning have not changed despite changes to the
32 | text of the warning itself.
33 |
34 | ### When do I get this error?
35 |
36 | The "Unnecessary 'else' after disruption" error (and the alternative "Unexpected
37 | 'else' after 'return'" error) is thrown when JSLint or ESLint encounters **an
38 | `else` block following an `if` block that contains a disruptive statement such
39 | as `return` or `throw`**. Here's some example code:
40 |
41 |
46 | ```javascript
47 | function example(x) {
48 | "use strict";
49 | if (!x) {
50 | throw "A throw is disruptive";
51 | } else {
52 | return true;
53 | }
54 | }
55 | ```
56 |
57 | ESLint will only raise this error when it encounters a `return` statement and
58 | not a `throw` statement:
59 |
60 |
65 | ```javascript
66 | function example(x) {
67 | "use strict";
68 | if (!x) {
69 | return "A return is disruptive";
70 | } else {
71 | return false;
72 | }
73 | }
74 | ```
75 |
76 | ### Why do I get this error?
77 |
78 | This error is raised to highlight a **completely pointless piece of code**. If
79 | execution enters the `if` block, the flow of execution will be disrupted (it
80 | could for example return or throw an exception). There will be no way execution
81 | can enter the `else` block. Therefore, you can simply omit the `else` block and
82 | place its contents directly after the `if` block. Here's the above snippet
83 | again, without the error:
84 |
85 |
90 | ```javascript
91 | function example(x) {
92 | "use strict";
93 | if (!x) {
94 | throw "A throw is disruptive";
95 | }
96 | return true;
97 | }
98 | ```
99 |
100 | In ESLint the rule that generates this warning is named `no-else-return`. You
101 | can disable it by setting it to `0`, or enable it by setting it to `1`.
102 |
103 | [iife]: http://benalman.com/news/2010/11/immediately-invoked-function-expression
104 | [jshintopts]: http://jshint.com/docs/#options
105 |
--------------------------------------------------------------------------------
/message-articles/unnecessary-escapement.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### History
19 |
20 | This warning has existed in two forms in JSLint. It was introduced in the
21 | original version and has remained ever since. It is not present in JSHint or
22 | ESLint.
23 |
24 | - In JSLint versions dated December 2010 and earlier the warning given is
25 | "Unnecessary escapement"
26 |
27 | - In more recent versions the message has changed to "Unexpected '\'"
28 |
29 | The situations that produce the warning have not changed despite changes to the
30 | text of the warning itself.
31 |
32 | ### When do I get this error?
33 |
34 | The "Unnecessary escapement" error (and the alternative "Unexpected '\') is
35 | thrown when JSLint encounters **a string containing a unicode or hexadecimal
36 | escape sequence that could be replaced with the literal character**. In the
37 | following example we use the unicode escape sequence for the | (vertical line)
38 | character:
39 |
40 |
45 | ```javascript
46 | var title = "My Website \u007c Welcome";
47 | ```
48 |
49 | ### Why do I get this error?
50 |
51 | This error is raised to highlight a **potentially confusing piece of code**.
52 | When the character in question is safely represented without an escape sequence
53 | it is generally preferrable not to use an escape sequence because it makes the
54 | code easier to read. It would be difficult to know exactly what character is
55 | represented by `\u007c` in the above example without looking it up.
56 |
57 | The error is easily resolved by simply replacing unnecessary escape sequences
58 | with the appropriate characters:
59 |
60 |
65 | ```javascript
66 | var title = "My Website | Welcome";
67 | ```
68 |
--------------------------------------------------------------------------------
/message-articles/unnecessary-semicolon.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### When do I get this error?
20 |
21 | The "Unnecessary semicolon" error is thrown when JSHint or ESLint encounters **a semicolon following a block statement or function declaration**. In the following example we mistakenly include a semicolon after an `if` statement body (which is a block statement), and another after a function declaration:
22 |
23 |
28 | ```javascript
29 | function example(a) {
30 | "use strict";
31 | if (a) {
32 | return true;
33 | };
34 | };
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a **pointless piece of code**. Semicolons are
40 | not required after block statements or function declarations. The specification
41 | makes it clear where semicolons are necessary. For example, here's the grammar
42 | for variable declarations ([ES5 §12.2][es5-12.2]):
43 |
44 | > *VariableStatement* :
45 | > `var` *VariableDeclarationList* `;`
46 |
47 | The semicolon is clearly required by this production. Now compare that to the
48 | grammar for a block statement ([ES5 §12.1][es5-12.1]):
49 |
50 | > *Block* :
51 | > `{` *StatementList*opt `}`
52 |
53 | This time there is no semicolon which means its safe to remove the extra
54 | semicolons from the previous example. This will resolve the issue:
55 |
56 |
61 | ```javascript
62 | function example(a) {
63 | "use strict";
64 | if (a) {
65 | return true;
66 | }
67 | }
68 | ```
69 |
70 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
71 | [special option syntax][jshintopts]. The identifier of this warning is **W032**.
72 | This means you can tell JSHint to not issue this warning with the `/*jshint
73 | -W032 */` directive.
74 |
75 | In ESLint the rule that generates this warning is named `no-extra-semi`. You can
76 | disable it by setting it to `0`, or enable it by setting it to `1`.
77 |
78 | [es5-12.2]: http://es5.github.io/#x12.2
79 | [es5-12.1]: http://es5.github.io/#x12.1
80 | [jshintopts]: http://jshint.com/docs/#options
81 |
--------------------------------------------------------------------------------
/message-articles/unnecessary-strict.md:
--------------------------------------------------------------------------------
1 |
22 |
23 | ### When do I get this error?
24 |
25 | The "Unnecessary 'use strict'" error (and the alternative "Unnecessary directive
26 | '{a}'" error) is thrown when JSLint, JSHint or ESLint encounters **a `"use
27 | strict"` directive in code that is already running in strict mode**. The
28 | following example features a factory function that runs in strict mode and
29 | returns another function that has its own strict mode directive:
30 |
31 |
36 | ```javascript
37 | function factory() {
38 | "use strict";
39 | return function () {
40 | "use strict";
41 | return true;
42 | };
43 | }
44 | ```
45 |
46 | ### Why do I get this error?
47 |
48 | This error is raised to highlight a **completely pointless piece of code**. The
49 | `"use strict"` directive applies to the scope in which it appears, and any
50 | descendant execution contexts. Here's what the ECMAScript 5 specification tells
51 | us about strict mode and functions ([ES5 §10.1.1][es5-10.1.1]):
52 |
53 | > Function code that is part of a *FunctionDeclaration*, *FunctionExpression*,
54 | > or accessor *PropertyAssignment* is strict function code if its
55 | > *FunctionDeclaration*, *FunctionExpression*, or *PropertyAssignment* is
56 | > contained in strict mode code or if the function code begins with a Directive
57 | > Prologue that contains a Use Strict Directive.
58 |
59 | If you're receiving this error you can safely remove the highlighted instances
60 | of the `"use strict"` directive and be sure that the function in question will
61 | still run in strict mode:
62 |
63 |
68 | ```javascript
69 | function factory() {
70 | "use strict";
71 | return function () {
72 | return true;
73 | };
74 | }
75 | ```
76 |
77 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
78 | [special option syntax][jshintopts]. The identifier of this warning is **W034**.
79 | This means you can tell JSHint to not issue this warning with the `/*jshint
80 | -W034 */` directive.
81 |
82 | In ESLint the rule that generates this warning is named `no-extra-strict`. You
83 | can disable it by setting it to `0`, or enable it by setting it to `1`.
84 |
85 | [es5-10.1.1]: http://es5.github.io/#x10.1.1
86 | [jshintopts]: http://jshint.com/docs/#options
87 |
--------------------------------------------------------------------------------
/message-articles/unregistered-property-name.md:
--------------------------------------------------------------------------------
1 |
22 |
23 | ### History
24 |
25 | This warning has existed in a number of forms in both JSLint and JSHint. It was
26 | introduced in the original version of both and has remained ever since.
27 |
28 | - In JSLint versions dated before May 2015 the warning given is "Unexpected
29 | /\*property\*/ '{a}'"
30 |
31 | - In more recent versions the message has changed to "Unregistered property
32 | name '{a}'"
33 |
34 | - In JSHint the message has always been "Unexpected /*member '{a}'"
35 |
36 | The situations that produce the warning have not changed despite changes to the
37 | text of the warning itself.
38 |
39 | ### When do I get this error?
40 |
41 | The "Unregistered property name '{a}'" error (and the alternatives, "Unexpected
42 | /\*property\*/ '{a}'" and "Unexpected /\*member '{a}'") is thrown when JSLint or
43 | JSHint encounters **a non-whitelisted property identifier**. In the following
44 | example we are attempting to create an object literal with a property named `x`:
45 |
46 |
51 | ```javascript
52 | /*property y, z */
53 | var obj = {
54 | x: 1
55 | };
56 | ```
57 |
58 | ### Why do I get this error?
59 |
60 | This error is raised to highlight a **possible typo** or a **deviation from a
61 | code style guide**. Unless the message is indicating a typo it's likely that
62 | your code will work without fault but you may be breaking rules set by your
63 | organization.
64 |
65 | This error will only be thrown if the linter configuration specifies a property
66 | name whitelist. In JSLint this is likely to appear in the form of a `/*property
67 | */` directive at the top of the file. In older versions of JSLint `/*properties
68 | */` was also accepted. In JSHint the relevant directive is `/*members */`. Note
69 | that the `/*members */` directive in JSHint is deprecated and this functionality
70 | is likely to be removed in a future version.
71 |
72 | To resolve the issue ensure you are only referencing properties that are
73 | whitelisted. Alternatively, add the property identifier in question to the list.
74 |
75 | ```javascript
76 | /*property x, y, z */
77 | var obj = {
78 | x: 1
79 | };
80 | ```
81 |
82 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
83 | [special option syntax][jshintopts]. The identifier of this warning is **W036**.
84 | This means you can tell JSHint to not issue this warning with the `/*jshint
85 | -W036 */` directive.
86 |
87 | [jshintopts]: http://jshint.com/docs/#options
88 |
--------------------------------------------------------------------------------
/message-articles/unused-expression.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Expected an assignment or function call and instead saw an expression"
23 | error is thrown when JSLint, JSHint or ESLint encounters **an expression with no
24 | effect**. In the following example we have a conditional expression that will
25 | evaluate to `true` but has no other effect on the program:
26 |
27 |
32 | ```javascript
33 | var x = 1;
34 | x === 1; // Evaluates to 'true'
35 | ```
36 |
37 | ### Why do I get this error?
38 |
39 | This error is raised to highlight a piece of **useless and unnecessary code**.
40 | The code will work as expected but since a lone floating expression has no
41 | effect on anything there is no point in it being there at all.
42 |
43 | In general you would expect to see a statement which has an effect, such as
44 | assigning a value to a variable or invoking a function:
45 |
46 |
51 | ```javascript
52 | var x = 1;
53 | x = 2; // Assignment instead of unused expression
54 | ```
55 |
56 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
57 | [special option syntax][jshintopts]. The identifier of this warning is **W030**.
58 | This means you can tell JSHint to not issue this warning with the `/*jshint
59 | -W030 */` directive.
60 |
61 | In ESLint the rule that generates this warning is named `no-unused-expressions`.
62 | You can disable it by setting it to `0`, or enable it by setting it to `1`.
63 |
64 | [jshintopts]: http://jshint.com/docs/#options
65 |
--------------------------------------------------------------------------------
/message-articles/uppercase-constructor.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### When do I get this error?
23 |
24 | The "A constructor name should start with an uppercase letter" error is thrown
25 | when JSLint, JSHint or ESLint encounters **an identifier, preceded by the `new`
26 | operator, whose first character is a lowercase letter**. JSHint will only raise
27 | this warning **when the `newcap` option is set to `true`**. In the following
28 | example we declare a constructor function `myConstructor` and then attempt to
29 | instantiate it:
30 |
31 |
36 | ```javascript
37 | /*jshint newcap: true */
38 | function myConstructor() {
39 | "use strict";
40 | this.property = "Something";
41 | }
42 |
43 | var myInstance = new myConstructor();
44 | ```
45 |
46 | ### Why do I get this error?
47 |
48 | This error is raised to highlight a **lack of convention**. It is common practice for constructor function identifiers to begin with an uppercase letter. JSLint simply enforces this convention. Here's the above snippet rewritten to pass JSLint. Notice that the only difference is the uppercase "M":
49 |
50 |
55 | ```js
56 | /*jshint newcap: true */
57 | function MyClass() {
58 | "use strict";
59 | this.property = "Something";
60 | }
61 |
62 | var myInstance = new MyClass();
63 | ```
64 |
65 | It is worth bearing in mind that this is only a convention and is not required
66 | by the language in any way. You can safely ignore this error if you prefer to
67 | name your constructor functions differently. By setting the `newcap` option, you
68 | can tell JSLint to allow lowercase constructors.
69 |
70 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
71 | [special option syntax][jshintopts]. The identifier of this warning is **W055**.
72 | This means you can tell JSHint to not issue this warning with the `/*jshint
73 | -W055 */` directive.
74 |
75 | [es5-12.2]: http://es5.github.com/#x12.2
76 | [jshintopts]: http://jshint.com/docs/#options
77 |
--------------------------------------------------------------------------------
/message-articles/use-isnan.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Use the isNaN function to compare with NaN" error is thrown when JSLint,
23 | JSHint and ESLint encounter **a comparison in which one side is `NaN`**. In the
24 | following example we attempt to convert a string into a number with the
25 | `parseInt` function, which returns `NaN` when it can't perform such a
26 | conversion:
27 |
28 |
33 | ```javascript
34 | var x = parseInt("myString", 10);
35 | if (x === NaN) {
36 | x = 10;
37 | }
38 | ```
39 |
40 | ### Why do I get this error?
41 |
42 | This error is raised to highlight **code that doesn't work as you expect it
43 | to**. Your code will run without error, but will not behave as you expect. `NaN`
44 | is a special value of the `Number` type. It's used to represent any of the
45 | "not-a-number" values represented by the double-precision 64-bit format as
46 | specified by the IEEE Standard for Binary Floating-Point Arithmetic. `NaN` has
47 | the unique property of not being equal to *anything*, including itself. That is
48 | to say, that the condition `NaN !== NaN` evaluates to true.
49 |
50 | The strict equality comparison algorithm ([ES5 §11.9.6][es5-11.9.6])
51 | specifically handles the `NaN` value:
52 |
53 | > The comparison *x* === *y*, where *x* and *y* are values, produces true or
54 | > false. Such a comparison is performed as follows:
55 | > ...
56 | > 4. If Type(*x*) is Number, then
57 | > a. If *x* is NaN, return
58 | > false.
59 | > b. If *y* is NaN, return
60 | > false.
61 | > ...
62 |
63 | The abstract equality comparison algorithm ([ES5 §11.9.3][es5-11.9.3])
64 | behaves in exactly the same way. This means that when you attempt to compare
65 | something to `NaN`, the condition will always evaluate to `false`.
66 |
67 | To fix this error, as the message suggests, you can use the `isNaN` function,
68 | which is a built-in property of the global object. It's defined in [ES5
69 | §15.1.2.4][es5-15.1.2.4] and simply returns `true` if its argument coerces
70 | to `NaN`, and `false` if it does not:
71 |
72 |
77 | ```javascript
78 | var x = parseInt("myString", 10);
79 | if (isNaN(x)) {
80 | x = 10;
81 | }
82 | ```
83 |
84 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
85 | [special option syntax][jshintopts]. The identifier of this warning is **W019**.
86 | This means you can tell JSHint to not issue this warning with the `/*jshint
87 | -W019 */` directive.
88 |
89 | In ESLint the rule that generates this warning is named `use-isnan`. You can
90 | disable it by setting it to `0`, or enable it by setting it to `1`.
91 |
92 | [es5-11.9.6]: http://es5.github.com/#x11.9.6
93 | [es5-11.9.3]: http://es5.github.com/#x11.9.3
94 | [es5-15.1.2.4]: http://es5.github.com/#x15.1.2.4
95 | [jshintopts]: http://jshint.com/docs/#options
96 |
--------------------------------------------------------------------------------
/message-articles/use-named-param.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Use a named parameter" error is thrown when JSLint encounters a **access a
19 | property of the arguments object by numerical index**. The following example
20 | adds two numbers. Since the function has no named parameters it uses the
21 | `arguments` object:
22 |
23 |
28 | ```javascript
29 | function add2() {
30 | "use strict";
31 | return arguments[0] + arguments[1];
32 | }
33 | ```
34 |
35 | ### Why do I get this error?
36 |
37 | This error is raised to highlight **potentially slow and potentially confusing
38 | code**. Using the `arguments` object is slow. Many JavaScript engines will not
39 | actually create the object unless you reference it within a function. Running a
40 | [benchmark][perf] in Chrome 30.0 reveals a 54% performance improvement when
41 | using named arguments.
42 |
43 | As well as the performance issues, using the `arguments` object over named
44 | parameters harms the readability of your code. It is much easier to understand
45 | what a function is going to do, and what you should be passing it, when that
46 | information is available from the signature. To solve this error, simply use
47 | named function parameters where possible:
48 |
49 |
54 | ```javascript
55 | // This is much easier to understand
56 | function add2(firstNumber, secondNumber) {
57 | "use strict";
58 | return firstNumber + secondNumber;
59 | }
60 | ```
61 |
62 | Note, however, that there are valid use cases for the `arguments` object. JSLint
63 | will only warn when you attempt to access a property of it by numeric index. The
64 | reason for this is that if you know the position of the argument in the list,
65 | there should be no reason you cannot give it an identifier in the function
66 | signature. Here's an example of a slightly more useful `add` function which uses
67 | the `arguments` object to allow the addition of any number of arguments:
68 |
69 |
74 | ```javascript
75 | /*jslint plusplus: true */
76 | function add() {
77 |
78 | "use strict";
79 |
80 | var total = 0,
81 | i;
82 |
83 | for (i = 0; i < arguments.length; i++) {
84 | total += arguments[i];
85 | }
86 |
87 | return total;
88 | }
89 | ```
90 |
91 | This passes JSLint because we are no longer using a numeric index directly to
92 | access an argument. Even though `i` refers to a number JSLint will allow this to
93 | pass as it's a valid use case for the `arguments` object.
94 |
95 | [perf]: http://jsperf.com/named-arguments-vs-arguments-object
96 |
--------------------------------------------------------------------------------
/message-articles/use-or.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Use the || operator" error is thrown when JSLint encounters a **conditional
19 | operator in which the logical expression and first assignment expression are
20 | identical**. In the following example we use the conditional operator to provide
21 | default values to function arguments when that argument has no existing value:
22 |
23 |
28 | ```javascript
29 | function example(a, b) {
30 | "use strict";
31 | a = a ? a : "Default";
32 | b = b ? b : "Another";
33 | }
34 | ```
35 |
36 | ### Why do I get this error?
37 |
38 | This error is raised to highlight **unnecessarily verbose and potentially
39 | confusing code**. The use of the conditional operator in this case can be
40 | replaced with the logical or operator `||` which does exactly the same thing:
41 |
42 |
47 | ```javascript
48 | function example(a, b) {
49 | "use strict";
50 | a = a || "Default";
51 | b = b || "Another";
52 | }
53 | ```
54 |
55 | This works because the `||` operator does not return a boolean value as you
56 | might expect. Instead it will return the result of evaluating one of its
57 | operands ([ES5 §11.11][es5-11.11]):
58 |
59 | > The value produced by a `&&` or `||` operator is not necessarily of type
60 | > Boolean. The value produced will always be the value of one of the two operand
61 | > expressions.
62 |
63 | The `||` operator evaluates its first operand and if the result is falsy then
64 | evaluates the second and returns the result. In the previous example if `b` is
65 | undefined then the first operand will be falsy which results in the second
66 | operand `"Another"` being the result of the expression.
67 |
68 | [es5-11.11]: http://es5.github.io/#x11.11
69 |
--------------------------------------------------------------------------------
/message-articles/use-quote.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### When do I get this error?
23 |
24 | The "Strings must use singlequote" and "Strings must use doublequote" errors are
25 | thrown when JSHint or ESLint encounters **string literal delimited by double
26 | quote characters when the `quotmark` option is set to `single`** or a **string
27 | literal delimited by single quote characters when the `quotmark` option is set
28 | to `double`**. In the following example we attempt to assign a string literal
29 | to the variable `x`:
30 |
31 |
36 | ```javascript
37 | /*jshint quotmark: double */
38 | var x = 'My String';
39 | ```
40 |
41 | ### Why do I get this error?
42 |
43 | This error is raised to highlight a **deviation from a specific coding style**.
44 | Your code will run fine if you do not fix this error, but it demonstrates a lack
45 | of care. There is no difference in JavaScript between single and double quotes.
46 | This is made clear by the grammar for string literals ([ES5
47 | §7.8.4][es5-7.8.4]):
48 |
49 | > *StringLiteral* ::
50 | > `"` *DoubleStringCharacters*opt `"`
51 | > `'` *SingleStringCharacters*opt `'`
52 |
53 | The only difference is that *DoubleStringCharacters* cannot contain another
54 | double quote, and *SingleStringCharacters* cannot contain a single quote (as
55 | that would terminate the string literal). If this option is set to either
56 | `double` or `single` then it is likely your codebase requires you to conform to
57 | a specific style in which one type of quote is preferred. To fix the error,
58 | simply use the correct type of quote:
59 |
60 |
65 | ```javascript
66 | /*jshint quotmark: double */
67 | var x = "My String";
68 | ```
69 |
70 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
71 | [special option syntax][jshintopts]. The identifier of this warning is **W108**
72 | (for double quotes) or **W109** (for single quotes). This means you can tell
73 | JSHint to not issue this warning with the `/*jshint -W108 */` or `/*jshint -W109
74 | */` directive.
75 |
76 | [es5-7.8.4]: http://es5.github.io/#x7.8.4
77 | [jshintopts]: http://jshint.com/docs/#options
78 |
--------------------------------------------------------------------------------
/message-articles/valid-trailing-decimal.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### When do I get this error?
19 |
20 | The "A dot following a number can be confused with a decimal point" error is
21 | thrown when JSHint encounters **a numeric literal containing a decimal point as
22 | the left-hand-side of a member expression**. In the following example we attempt
23 | to assign the string representation of a number to a variable:
24 |
25 |
30 | ```javascript
31 | var a = 5.4.toString();
32 | ```
33 |
34 | Note that this is slightly different to closely related "[A trailing decimal
35 | point can be consued with a dot][trailing]" error, although JSLint will use that
36 | message in this situation too.
37 |
38 | ### Why do I get this error?
39 |
40 | This error is raised to highlight a **potentially confusing piece of code**.
41 | Your script will run without error if you do not change it, but it could be
42 | confusing to other developers, especially at first glance.
43 |
44 | Since a number can only contain a single decimal point the parser is able to
45 | determine that any subsequent occurences of the character after a numeric
46 | literal can only be intended as a member operator. In other words the ambiguity
47 | of the `.` character is removed. However the construct can appear confusing at
48 | first glance.
49 |
50 | The best solution in this case is to wrap the number in parentheses:
51 |
52 |
57 | ```javascript
58 | var a = (5.4).toString();
59 | ```
60 |
61 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
62 | [special option syntax][jshintopts]. The identifier of this
63 | warning is **W005**. This means you can tell JSHint to not issue this warning
64 | with the `/*jshint -W005 */` directive.
65 |
66 | [trailing]: /a-trailing-decimal-point-can-be-confused-with-a-dot-a
67 | [jshintopts]: http://jshint.com/docs/#options
68 |
--------------------------------------------------------------------------------
/message-articles/variable-delete.md:
--------------------------------------------------------------------------------
1 |
21 |
22 | ### History
23 |
24 | This warning has existed in two forms in JSLint, JSHint and ESLint. It was
25 | introduced in the original version of JSLint and has remained in all three tools
26 | ever since.
27 |
28 | - In JSLint the warning given is *"Only properties should be deleted"*
29 |
30 | - In JSHint and ESLint the warning has always been *"Variables should not be
31 | deleted"*
32 |
33 | The situations that produce the warning have not changed despite changes to the
34 | text of the warning itself.
35 |
36 | ### When do I get this error?
37 |
38 | The "Only properties should be deleted" error, and the alternative "Variables
39 | should not be deleted" error, is thrown when JSLint, JSHint or ESLint
40 | encounters **the `delete` operator followed by a single identifier**. In the
41 | following example we declare a variable x and then attempt to delete it:
42 |
43 |
48 | ```javascript
49 | var x = 10;
50 | delete x;
51 | ```
52 |
53 | ### Why do I get this error?
54 |
55 | This error is raised to highlight code that probably **doesn't work as you
56 | expect it to**. It can also indicate a **fatal syntax error**. The `delete`
57 | operator will only delete properties of objects. It cannot "delete" variables or
58 | anything else. Here's a valid use of the delete operator. Notice how this time
59 | there are no JSLint errors:
60 |
61 |
66 | ```js
67 | var x = {
68 | prop: 10
69 | };
70 | delete x.prop;
71 | ```
72 |
73 | The ECMAScript 5 specification details the behaviour of the `delete` operator
74 | ([ES5 §11.4.1][es5-11.4.1]). When the operand is a reference to an object
75 | property this is what happens:
76 |
77 | > If IsPropertyReference(ref) is true, then
78 | > Return the result of calling the [[Delete]] internal
79 | > method on ToObject(GetBase(ref)) providing GetReferencedName(ref) and
80 | > IsStrictReference(ref) as the arguments.
81 |
82 | But when the operand is a reference to an Environment Record binding (something
83 | that is not an object property), the runtime will attempt to delete it (and
84 | fail) unless the code is running in strict mode. In that case a syntax error is
85 | thrown:
86 |
87 | > Else, ref is a Reference to an Environment Record binding, so
88 | > If IsStrictReference(ref) is true, throw a SyntaxError
89 | > exception.
90 | > ...[attempt to delete]...
91 |
92 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
93 | [special option syntax][jshintopts]. The identifier of this warning is **W051**.
94 | This means you can tell JSHint to not issue this warning with the `/*jshint
95 | -W051 */` directive.
96 |
97 | [es5-11.4.1]: http://es5.github.io/#x11.4.1
98 | [jshintopts]: http://jshint.com/docs/#options
99 |
--------------------------------------------------------------------------------
/message-articles/weird-assignment.md:
--------------------------------------------------------------------------------
1 |
15 |
16 | ### When do I get this error?
17 |
18 | The "Weird assignment" error is thrown when JSLint encounters **an assignment
19 | expression in which the left hand side and right hand side expressions are the
20 | same**. In the following example we declare a variable `x` and then attempt to
21 | assign it to itself:
22 |
23 |
28 | ```javascript
29 | var x = 10;
30 | x = x;
31 | ```
32 |
33 | ### Why do I get this error?
34 |
35 | This error is raised to highlight a **potentially confusing and completely
36 | pointless piece of code**. There are almost no situations in which you would
37 | need to assign something to itself. There is, however, at least one valid use
38 | case.
39 |
40 | In the browser you can assign `window.location` to itself to force a page reload
41 | without reposting any form data. Calling `window.location.reload()` can cause a
42 | browser warning when form data will be reposted. To avoid that warning it's
43 | common to use one of the following patterns:
44 |
45 |
50 | ```javascript
51 | /*jslint browser: true */
52 | window.location = window.location;
53 | window.location.href = window.location.href;
54 | ```
55 |
56 | As you can see, both of those cause the "Weird assignment" error. It's a simple
57 | fix though. Since `window.location` is effectively an alias for
58 | `window.location.href` they are interchangable which means we can make the two
59 | sides of the assignment different:
60 |
61 |
66 | ```javascript
67 | /*jslint browser: true */
68 | window.location = window.location.href;
69 | ```
70 |
--------------------------------------------------------------------------------
/message-articles/weird-relation.md:
--------------------------------------------------------------------------------
1 |
18 |
19 | ### History
20 |
21 | This warning has existed in two forms in JSLint and ESLint. It was introduced in
22 | the original version of JSLint and has remained in both tools since. It is not
23 | present in JSHint.
24 |
25 | - In JSLint the warning given is *"Weird relation"*
26 |
27 | - In ESLint the message used is *"Comparing to itself is potentially
28 | pointless"*
29 |
30 | The situations that produce the warning have not changed despite changes to the
31 | text of the warning itself.
32 |
33 | ### When do I get this error?
34 |
35 | The "Weird relation" error is thrown when JSLint or ESLint encounters **a
36 | comparison in which the left hand side and right hand side are the same**. In
37 | the following example we attempt to compare `x` with itself:
38 |
39 |
44 | ```javascript
45 | var x = 10;
46 | if (x === x) {
47 | x = 20;
48 | }
49 | ```
50 |
51 | JSLint will also raise this error when it encounters **a comparison in which
52 | either the left hand side or right hand side is a string literal and the other
53 | is a numeric literal**. In the next example we attempt to compare the string
54 | `"10"` to the number `10`:
55 |
56 |
61 | ```javascript
62 | var x = 10;
63 | if ("10" === 10) {
64 | x = 20;
65 | }
66 | ```
67 |
68 | ### Why do I get this error?
69 |
70 | This error is raised to highlight a **potentially confusing and potentially
71 | pointless piece of code**. There are almost no situations in which you would
72 | need to compare something to itself. There is, however, at least one valid use
73 | case.
74 |
75 | Since the special numeric value `NaN` is never equal to itself, you can use a
76 | self-comparison to check whether some value is `NaN`. See the somewhat related
77 | "[Use the isNaN function to compare with NaN][isnan]" for further discussion
78 | around this. The following example will return true only if the value is `NaN`:
79 |
80 |
85 | ```javascript
86 | var x = parseInt("x", 10); // Results in NaN
87 | if (x !== x) {
88 | x = 20; // Only if 'x' is NaN
89 | }
90 | ```
91 |
92 | If you are receiving this error for this specific use case, you can either
93 | ignore the error and let your script fail the JSLint test, or you can use the
94 | built-in isNaN function instead. Here's the above snippet rewritten:
95 |
96 |
101 | ```javascript
102 | var x = parseInt("x", 10); // Results in NaN
103 | if (isNaN(x)) {
104 | x = 20; // Only if 'x' is NaN
105 | }
106 | ```
107 |
108 | [isnan]: /use-the-isnan-function-to-compare-with-nan
109 |
--------------------------------------------------------------------------------
/message-articles/with-strict.md:
--------------------------------------------------------------------------------
1 |
20 |
21 | ### History
22 |
23 | This warning has existed in two forms in JSHint and ESLint. It was introduced in
24 | the original version of JSLHnt and has remained in both tools since. It does not
25 | feature in JSLint.
26 |
27 | - In JSHint the message used is "'with' is not allowed in strict mode"
28 |
29 | - In ESLint the message has always been "Strict mode code may not include a
30 | with statement"
31 |
32 | The situations that produce the warning have not changed despite changes to the
33 | text of the warning itself.
34 |
35 | ### When do I get this error?
36 |
37 | The "'with' is not allowed in strict mode" error, and the alternative "Strict
38 | mode code may not include a with statement", is thrown when JSHint or ESLint
39 | encounters **the `with` statement in code that is running in strict mode**.
40 | Here's an example:
41 |
42 |
47 | ```javascript
48 | function example() {
49 | "use strict";
50 | var a = {
51 | b: 10
52 | };
53 | with (a) {
54 | b = 20;
55 | }
56 | }
57 | ```
58 |
59 | ### Why do I get this error?
60 |
61 | This error is raised to highlight a **fatal JavaScript syntax error**. Your code
62 | will fail to run in any environment that supports strict mode. The ECMAScript 5
63 | specification clearly states that the presence of a `with` statement within
64 | strict mode code is illegal ([ES5 §12.10.1][es5-12.10.1]):
65 |
66 | > Strict mode code may not include a *WithStatement*. The occurrence of a
67 | > *WithStatement* in such a context is treated as a SyntaxError.
68 |
69 | You can solve this problem by reworking code that uses `with` statements to
70 | fully qualify the "namespace". The following example will behave in exactly the
71 | same way as the first example above:
72 |
73 |
78 | ```javascript
79 | function example() {
80 | "use strict";
81 | var a = {
82 | b: 10
83 | };
84 | a.b = 20;
85 | }
86 | ```
87 |
88 | If you rely upon the behaviour of the `with` statement for a valid use-case,
89 | your only option is to ensure your code does not run in strict mode. This
90 | results in a different message from JSHint, but one that can be surpressed (in
91 | version 1.0.0 and above) with the appropriate warning identifier flag. See the
92 | page on the "[Don't use with][with]" error for more details:
93 |
94 |
99 | ```javascript
100 | function example() {
101 | var a = {
102 | b: 10
103 | };
104 | with (a) {
105 | b = 20;
106 | }
107 | }
108 | ```
109 |
110 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
111 | [special option syntax][jshintopts]. Since this message relates to a fatal
112 | syntax error you cannot disable it.
113 |
114 | [es5-12.10.1]: http://es5.github.com/#x12.10.1
115 | [with]: /unexpected-with
116 | [jshintopts]: http://jshint.com/docs/#options
117 |
--------------------------------------------------------------------------------
/message-articles/wrap-iife.md:
--------------------------------------------------------------------------------
1 |
19 |
20 | ### When do I get this error?
21 |
22 | The "Wrap an immediate function invocation in parentheses" error is thrown when
23 | JSLint, JSHint and ESLint encounter **an immediately invoked function expression
24 | that is not wrapped in parentheses**. JSHint will only raise this warning if the
25 | `immed` option is set to `true`. In the following example we assign the return
26 | value of the anonymous function the variable `x`:
27 |
28 |
34 | ```javascript
35 | /*jshint immed: true */
36 | var x = function () {
37 | "use strict";
38 | return {
39 | y: 1
40 | };
41 | }();
42 | ```
43 |
44 | ### Why do I get this error?
45 |
46 | This error is raised to highlight a **lack of convention**. Your code will run
47 | fine if you do not fix this error, but it may be confusing to others. Since
48 | function declarations cannot be immediately invoked, and function expressions
49 | can be, a common technique to create an immediately-invoked function expression
50 | is to simply wrap a function statement in parentheses. The opening parenthesis
51 | causes the contained function to be parsed as an expression, rather than a
52 | declaration:
53 |
54 |
60 | ```javascript
61 | var x;
62 | (function () {
63 | "use strict";
64 | x = 10;
65 | }());
66 | ```
67 |
68 | If you remove the wrapping parentheses from the above example, you will end up
69 | with a syntax error. For that reason, when immediately invoking a function
70 | expression that doesn't require any special treatment to turn it into an
71 | expression (as in the first example above), convention dictates that you should
72 | wrap it in parentheses anyway, for consistency and to make it clearer that the
73 | resulting value of the overall expression is the *return value* of the function,
74 | rather than a reference to the function itself:
75 |
76 |
82 | ```javascript
83 | /*jshint immed: true */
84 | var x = (function () {
85 | "use strict";
86 | return {
87 | y: 1
88 | };
89 | }());
90 | ```
91 |
92 | In JSHint 1.0.0 and above you have the ability to ignore any warning with a
93 | [special option syntax][jshintopts]. The identifier of this warning is **W062**.
94 | This means you can tell JSHint to not issue this warning with the `/*jshint
95 | -W062 */` directive. You can also set the `immed` option to `false`.
96 |
97 | In ESLint the rule that generates this warning is named `wrap-iife`. You can
98 | disable it by setting it to `0`, or enable it by setting it to `1`.
99 |
100 | [jshintopts]: http://jshint.com/docs/#options
101 |
--------------------------------------------------------------------------------
/option-articles/bitwise.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### What does this option do?
19 |
20 | In JSLint the `bitwise` option is used to allow the usage of any bitwise
21 | operators. In JavaScript the available bitwise operators are `<<` (bitwise left
22 | shift), `>>` (bitwise right shift), `>>>` (unsigned bitwise right shift), `&`
23 | (bitwise AND), `|` (bitwise OR), `^` (bitwise XOR) and `~` (bitwise NOT). In the
24 | following example we are using the bitwise OR operator to round a number down to
25 | the closest integer which is a relatively common shorthand trick:
26 |
27 |
32 | ```javascript
33 | /*jslint bitwise: true */
34 | var x = 1.2345 | 0;
35 | ```
36 |
37 | The JSHint `bitwise` option is used to **disallow** the use of those operators.
38 | Here's the same example again:
39 |
40 |
45 | ```javascript
46 | /*jshint bitwise: true */
47 | var x = 1.2345 | 0;
48 | ```
49 |
50 | ### When should I use this option?
51 |
52 | With JSLint, if the `bitwise` option is not set, you'll get an "Unexpected
53 | '{a}'" error, where "{a}" is a bitwise operator, any time a bitwise operator is
54 | used. In JSHint the opposite is true and you'll receive an "Unexpected use of
55 | '{a}'" error for each bitwise operator occurence when the option is set.
56 |
57 | If you require the use of bitwise operators for actual program logic then you
58 | cannot enable this option. However, if you do not need to use such operators and
59 | want to prevent tricks such as the one shown above, enabling this option is a
60 | good way to do so.
61 |
62 | Note that in JSHint this is an *enforcing* option which means JSHint does not
63 | apply it by default. If you do not explicitly set this option to `true` JSHint
64 | will allow the use of bitwise operators anywhere in your code.
65 |
66 | #### Recommendation
67 |
68 | - **JSLint** - Set this option to `true` (you will be able to use bitwise
69 | operators).
70 |
71 | - **JSHint** - Do not set this option (you will be able to use bitwise
72 | operators).
73 |
--------------------------------------------------------------------------------
/option-articles/camelcase-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `camelcase` option is used to force all identifiers (function,
20 | variable and property) to either be written in camel case or in uppercase with
21 | underscores. It's common convention in JavaScript to use camel case for normal
22 | identifiers and uppercase for identifiers that represent constants. In the
23 | following example we have a couple of identifiers that break the camel case
24 | rule:
25 |
26 |
31 | ```javascript
32 | /*jshint camelcase: true */
33 | var camel_case = 1;
34 | var fake_constant = 2;
35 | var obj = {
36 | not_good: 3
37 | };
38 | ```
39 |
40 | In the next example we've changed the identifiers so they conform to the rules:
41 |
42 |
47 | ```javascript
48 | /*jshint camelcase: true */
49 | var camelCase = 1;
50 | var FAKE_CONSTANT = 2;
51 | var obj = {
52 | notGood: 3
53 | };
54 | ```
55 |
56 | ### When should I use this option?
57 |
58 | The use of the `camelcase` JSHint option will cause an "Identifier '{a}' is not
59 | in camel case" error, where "{a}" is the identifier in question, any time it
60 | encounters an identifier that doesn't match the rules discussed above. You
61 | should only enable this option when you want to enforce a coding style
62 | throughout your program. This is generally a good idea when you're working on a
63 | project with multiple developers to help keep things consistent.
64 |
65 | Note that this is an *enforcing* option which means JSHint does not apply it by
66 | default. If you do not explicitly set this option to `true` JSHint will allow
67 | the use of bitwise operators anywhere in your code.
68 |
69 | #### Recommendation
70 |
71 | Set this option to `true` (enforces the use of camel case and constant case).
72 |
--------------------------------------------------------------------------------
/option-articles/curly-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `curly` option is used to enforce the use of block statements
20 | following the `if`, `for`, `while` and `do` statements. The language grammar
21 | shows that these statements must be followed by another statement which is why
22 | it's possible to omit the curly braces for single-statement bodies such as the
23 | following:
24 |
25 |
30 | ```javascript
31 | /*jshint curly: true */
32 | while (x)
33 | y();
34 | z(); // This is not inside the loop
35 | ```
36 |
37 | ### When should I use this option?
38 |
39 | The use of the `curly` JSHint option will cause an "Expected '{' and instead saw
40 | '{b}'" error, where "{b}" is the statement following the statement in question,
41 | any time it encounters a statement that doesn't match the rules discussed above.
42 | As demonstrated in the above example the omission of curly braces can make it
43 | easier to introduce bugs into the code. In general you should use curly braces
44 | where possible and leave it up to your minification or build process to remove
45 | them where necessary. Therefore it's usually sensible to enable this option
46 | unless your coding guidelines ask for the shorter form.
47 |
48 | Note that this is an *enforcing* option which means JSHint does not apply it by
49 | default. If you do not explicitly set this option to `true` JSHint will allow
50 | the use of bitwise operators anywhere in your code.
51 |
52 | #### Recommendation
53 |
54 | Set this option to `true` (enforces the use of curly braces).
55 |
--------------------------------------------------------------------------------
/option-articles/eqeqeq-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `eqeqeq` option is used to prohibit the use of the equals operator
20 | `==` and the does-not-equal operator `!=`. This enforces the use of the strict
21 | equality operators (`===` and `!==` instead). The strict equality operators
22 | differ from their non-strict counterparts by first comparing the type of each
23 | operand, rather than attempting to coerce them to a common type. In the
24 | following example we make use of the non-strict equality operator to check
25 | whether a value is either `null` or `undefined`:
26 |
27 |
32 | ```javascript
33 | /*jshint eqeqeq: true */
34 | var x;
35 | if (x == null) {
36 | // This will execute if x is null or undefined
37 | doSomething();
38 | }
39 | ```
40 |
41 | ### When should I use this option?
42 |
43 | The use of the `eqeqeq` JSHint option will cause an "Expected '===' and instead
44 | saw '=='" error any time it encounters an equals or does-not-equal operator. As
45 | demonstrated in the above example these operators can be used in some situations
46 | to produce shorter code. However, their use can lead to bugs and unexpected
47 | behaviour. For that reason it's generally considered best practice to use the
48 | strict equality operators wherever possible. The example above can be written as
49 | follows instead:
50 |
51 |
56 | ```javascript
57 | /*jshint eqeqeq: true */
58 | var x;
59 | if (typeof x === "undefined" || x === null) {
60 | // This will execute if x is null or undefined
61 | doSomething();
62 | }
63 | ```
64 |
65 | Note that this is an *enforcing* option which means JSHint does not apply it by
66 | default. If you do not explicitly set this option to `true` JSHint will allow
67 | the use of non-strict equality operators anywhere in your code.
68 |
69 | #### Recommendation
70 |
71 | Set this option to `true` (enforces the use of strict equality operators).
72 |
--------------------------------------------------------------------------------
/option-articles/es3-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `es3` option is used to tell JSHint that your code will be running in
20 | a ECMAScript 3 environment (as opposed to ECMAScript 5, which is the current
21 | version of the standard). It was introduced in JSHint 2.0.0. This will disallow
22 | the use of various ES5 features and enable various error messages that apply
23 | only to older ES3 environments (such as Internet Explorer 8 and below). The
24 | following example defines a setter and a getter on an object. These features
25 | were introduced in the ES5 specification:
26 |
27 |
32 | ```javascript
33 | /*jshint es3: true */
34 | var person = {
35 | firstName: "James",
36 | lastName: "Brown",
37 | get name () {
38 | return this.firstName + " " + this.lastName;
39 | },
40 | set fullName (name) {
41 | var parts = name.split(" ");
42 | this.firstName = parts[0];
43 | this.lastName = parts[1];
44 | }
45 | };
46 | ```
47 |
48 | ### What errors can it cause?
49 |
50 | - "[Missing radix parameter][radix]"
51 |
52 | - "[Expected an identifier and instead saw '{a}' (a reserved word)][reserved]"
53 |
54 | - "[Extra comma. (it breaks older versions of IE)][comma]"
55 |
56 | - "[get/set are ES5 features][getset]"
57 |
58 | ### When should I use this option?
59 |
60 | The use of the `es3` JSHint option can cause various error messages that would
61 | not be produced otherwise. This is a good thing, but only if your code has to
62 | run in environments that do not conform to ECMAScript 5.
63 |
64 | Note that this is an *enforcing* option which means JSHint does not apply it by
65 | default. If you do not explicitly set this option to `true` JSHint will allow
66 | the use of ES5 features anywhere in your code. Also note that if you're using an
67 | older version of JSHint (prior to 2.0.0) this option will be unavailable and
68 | JSHint will *disallow* the use of ES5 features by default.
69 |
70 | #### Recommendation
71 |
72 | Set this option to `true` if you need to support Internet Explorer 8 and below.
73 |
74 | [radix]: /missing-radix-parameter
75 | [reserved]: /expected-an-identifier-and-instead-saw-a-a-reserved-word
76 | [comma]: /extra-comma
77 | [getset]: /get-set-are-es5-features
78 |
--------------------------------------------------------------------------------
/option-articles/forin.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### What does this option do?
19 |
20 | In JSLint the `forin` option is used to allow the usage of unfiltered for-in
21 | statements. Since the for-in statement will enumerate properties from the
22 | prototype chain and not just from the object in question, it can potentially
23 | cause problems if other code is modifying native prototypes without your
24 | knowledge. In the following example we use a for-in loop to iterate over the
25 | elements of an array. This is commonly called out as bad practice because
26 | enumerable methods added to `Array.prototype` will be produced:
27 |
28 |
33 | ```javascript
34 | /*jslint forin: true */
35 | /*global doSomething */
36 |
37 | var arr = [],
38 | i;
39 |
40 | for (i in arr) {
41 | doSomething(arr[i]);
42 | }
43 | ```
44 |
45 | The JSHint `forin` option is used to **require** the filtering of such loops.
46 | Here's the same example again:
47 |
48 |
53 | ```javascript
54 | /*jshint forin: true */
55 | /*global doSomething */
56 |
57 | var arr = [],
58 | i;
59 |
60 | for (i in arr) {
61 | doSomething(arr[i]);
62 | }
63 | ```
64 |
65 | A "filtered" for-in statement is one that ensures only properties that belong to
66 | the object in question are operated on. This is usually achieved by wrapping the
67 | body of the for-in in an `if` statement that makes sure each property is an
68 | "own" property of the object:
69 |
70 |
75 | ```javascript
76 | /*jshint forin: true */
77 | /*global doSomething */
78 |
79 | var arr = [],
80 | i;
81 |
82 | for (i in arr) {
83 | if (arr.hasOwnProperty(i)) {
84 | doSomething(arr[i]);
85 | }
86 | }
87 | ```
88 |
89 | ### When should I use this option?
90 |
91 | With JSLint, if the `forin` option is not set, you'll get a "[The body of a for
92 | in should be wrapped in an if statement to filter unwanted properties from the
93 | prototype][forin]" error any time an unfiltered for-in statement is used. In
94 | JSHint the opposite is true and you'll receive the same error message for each
95 | unfiltered for-in when the option *is* set.
96 |
97 | Note that in JSHint this is an *enforcing* option which means JSHint does not
98 | apply it by default. If you do not explicitly set this option to `true` JSHint
99 | will allow the use of bitwise operators anywhere in your code.
100 |
101 | #### Recommendation
102 |
103 | - **JSLint** - Do not set this option (you will not be able to use unfiltered
104 | for-in statements).
105 |
106 | - **JSHint** - Set this option to `true` (you will not be able to use unfiltered
107 | for-in statements).
108 |
109 | [forin]: /the-body-of-a-for-in-should-be-wrapped-in-an-if-statement
110 |
--------------------------------------------------------------------------------
/option-articles/freeze-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `freeze` option is used to disallow the extension of native object
20 | prototypes. This is often viewed as bad practice and was a relatively common
21 | source of bugs in older JavaScript environments. In the following example we
22 | attempt to add a method to reverse strings to the native `String` object:
23 |
24 |
29 | ```javascript
30 | /*jshint freeze: true */
31 | String.prototype.reverse = function () {
32 | return this.split("").reverse().join("");
33 | };
34 | ```
35 |
36 | The option does not prevent extension of native prototypes via the
37 | `Object.defineProperty` method since it allows you to safely extend such objects
38 | with non-enumerable properties:
39 |
40 |
45 | ```javascript
46 | /*jshint freeze: true */
47 | Object.defineProperty(String.prototype, "reverse", {
48 | value: function () {
49 | return this.split("").reverse().join("");
50 | }
51 | });
52 | ```
53 |
54 | *Side note*: the implementation of string reversal above is naive because it
55 | fails to take into account the way characters are encoded internally in
56 | JavaScript. See [this Stack Overflow answer][reverse] for a great explanation.
57 |
58 | ### When should I use this option?
59 |
60 | The use of the `freeze` JSHint option will cause an "[Extending prototype of
61 | native object: '{a}'][native]" error, where "{a}" is the native prototype in
62 | question, any time it encounters an assignment that matches the rules discussed
63 | above. It's generally considered bad practice to extend native prototypes
64 | because it makes it easier to introduce bugs related to property enumeration and
65 | shadowing. See the article discussing the "[Extending prototype of native
66 | object: '{a}'][native]" error message for more details.
67 |
68 | Note that this is an *enforcing* option which means JSHint does not apply it by
69 | default. If you do not explicitly set this option to `true` JSHint will allow
70 | the extension of native prototypes anywhere in your code.
71 |
72 | #### Recommendation
73 |
74 | Set this option to `true` (disallows the extension of native prototypes).
75 |
76 | [reverse]: http://stackoverflow.com/questions/958908/how-do-you-reverse-a-string-in-place-in-javascript/16776621#16776621
77 | [native]: /extending-prototype-of-native-object
78 |
--------------------------------------------------------------------------------
/option-articles/immed-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `immed` option is used to enforce the wrapping of immediately invoked
20 | function expressions in a pair of parentheses. This prevents the less common use
21 | of other operators to force a function declaration to be parsed as a function
22 | expression and ensures functions that would already be parsed as an expression
23 | to be wrapped in parentheses anyway to make the intentions clearer to the
24 | reader.
25 |
26 | In the following example the function is parsed as an expression as it's part of
27 | a variable statement. It is not necessary to wrap the function in parentheses to
28 | be able to invoke it immediately:
29 |
30 |
35 | ```javascript
36 | /*jshint immed: true */
37 | var MyModule = function () {
38 | return {
39 | someData: 1
40 | };
41 | }();
42 | ```
43 |
44 | Be aware that this option does not enforce the position of the wrapping
45 | parentheses. Some coding conventions specify that the closing wrapping
46 | parenthesis should appear before the invoking pair and others say it should come
47 | after.
48 |
49 | ### When should I use this option?
50 |
51 | The use of the `immed` JSHint option will cause a "[Wrap an immediate function
52 | invocation in parentheses][parens]" error any time it encounters an immediately
53 | invoked function expression that is not wrapped in parentheses. It's common
54 | convention to place an IIFE within parentheses because it makes your intentions
55 | immediately clear to readers of your code. If you glance at the example above
56 | you would most likely assume that `x` refers to the function itself rather than
57 | the return value of it. By wrapping the function in parentheses you're less
58 | likely to make that incorrect assumption:
59 |
60 |
65 | ```javascript
66 | /*jshint immed: true */
67 | var MyModule = (function () {
68 | return {
69 | someData: 1
70 | };
71 | }());
72 | ```
73 |
74 | Note that this is an *enforcing* option which means JSHint does not apply it by
75 | default. If you do not explicitly set this option to `true` JSHint will allow
76 | IIFEs without wrapping parentheses.
77 |
78 | #### Recommendation
79 |
80 | Set this option to `true` (enforces the wrapping of IIFEs).
81 |
82 | [jscs]: https://github.com/mdevils/node-jscs
83 | [parens]: /wrap-an-immediate-function-invocation-in-parentheses
84 |
--------------------------------------------------------------------------------
/option-articles/indent.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | ### What does this option do?
19 |
20 | In JSLint and JSHint the `indent` option is used to enforce a specific tab width
21 | in your code. Both tools make their own assumptions about when indentation
22 | should occur but are largely identical in this regard. In the following example
23 | we specify an indentation width of 4 spaces. Both tools expect the body of an
24 | `if` statement to be indented so both will warn if the identation is not of the
25 | required width:
26 |
27 |
32 | ```javascript
33 | /*jslint indent: 4 */
34 | function doSomething(x) {
35 | "use strict";
36 | if (x) {
37 | return;
38 | }
39 | }
40 | ```
41 |
42 | ### When should I use this option?
43 |
44 | With JSLint you'll get an "Expected '{a}' at column {b}, not column {c}" error
45 | any time an incorrect indentation width is found. In JSHint you'll get an
46 | "Expected '{a}' to have an indentation at {b} instead at {c}" error under the
47 | same circumstances. By enabling the validation of indentation you can ensure it
48 | remains consistent throughout your code which will make it much easier to read.
49 | Common values for this option are `4` and `2` but the exact number depends on
50 | your personal preference and existing conventions.
51 |
52 | Note that in JSHint this is an *enforcing* option which means JSHint does not
53 | apply it by default. If you do not explicitly set this option to an integer
54 | JSHint will not warn about indentation anywhere in your code.
55 |
56 | #### Recommendation
57 |
58 | - **JSLint** - Set this option to `2` or `4` to enable indentation validation
59 |
60 | - **JSHint** - Set this option to `2` or `4` to enable indentation validation
61 |
--------------------------------------------------------------------------------
/option-articles/latedef-jshint.md:
--------------------------------------------------------------------------------
1 |
16 |
17 | ### What does this option do?
18 |
19 | The JSHint `latedef` option is used to ensure variables and functions are
20 | declared before they are used. That is to say, the declarations appear
21 | physically in the source code above references to those declared variables or
22 | functions. Because declarations in JavaScript are hoisted to the top of the
23 | scope in which they occur it is perfectly safe to reference them earlier.
24 |
25 | In the following example the `doStuff` function declaration is hoisted to the
26 | top of the global scope so it is accessible throughout the program regardless of
27 | its position in the source:
28 |
29 |
34 | ```javascript
35 | /*jshint latedef: true */
36 | doStuff();
37 | function doStuff() {}
38 | ```
39 |
40 | ### When should I use this option?
41 |
42 | The use of the `latedef` JSHint option will cause a "['{a}' was used before it
43 | was defined][latedef]" error any time it encounters a reference to an identifier
44 | that has not yet been declared. By declaring variables and functions before you
45 | need to refer to them you can make your code easier to read through, since most
46 | people will read it from top to bottom. If a function is declared at the bottom
47 | of a file but used throughout the reader will have to scroll around to find the
48 | definition rather than immediately seeing it at the top.
49 |
50 |
55 | ```javascript
56 | /*jshint immed: true */
57 | function doStuff() {}
58 | doStuff();
59 | ```
60 |
61 | Note that this is an *enforcing* option which means JSHint does not apply it by
62 | default. If you do not explicitly set this option to `true` JSHint will allow
63 | references to appear before declarations.
64 |
65 | #### Recommendation
66 |
67 | Set this option to `true` (ensures declarations appear before references).
68 |
69 | [latedef]: /a-was-used-before-it-was-defined
70 |
--------------------------------------------------------------------------------