├── .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 | --------------------------------------------------------------------------------