-Builtin functions and objects defined in the JavaScript standard library can be shadowed or redefined in user code. -This is confusing and makes code hard to understand, so it should be avoided. -
- --Refactor the code to avoid shadowing or redefinition. For example, if a local variable has the same name as a standard -library builtin, it should be renamed. -
- -
-In the following example, the user-defined function eval shadows the builtin function eval
-defined in the standard library. It could be renamed evaluate to avoid confusion.
-
-Defining a method by assigning a closure to a property of the receiver object in the constructor -is inefficient, since a new closure is created for every instance. This wastes heap space and may -interfere with JIT compilation. -
- --Assign the function to a property of the prototype object instead. That way, all instances share -the same closure. -
- -
-In the following example, constructor Point defines method move by creating
-a new closure and storing it in the move property of each new instance. Consequently,
-p.move and q.move are different methods.
-
-It is better to instead define move on the prototype object Point.prototype
-like this:
-
-Avoid using x % 2 === 1 or x % 2 > 0 to check whether a number
-x is odd, or x % 2 !== 1 to check whether it is even.
-Such code does not work for negative numbers: for example, -5 % 2 equals
--1, not 1.
-
-Consider using x % 2 !== 0 to check for odd parity and x % 2 === 0
-to check for even parity.
-
-The following code snippet does not detect -9 as an odd number because -9 % 2
-is -1, not 1.
-The check should be rewritten as follows: -
- --In JavaScript, properties of objects do not have to be declared and can be dynamically added -and removed at runtime. Thus, if a property name is misspelled, this is not detected by the -compiler, and may lead to an error at runtime. The same problem occurs with misspelled -global variables. -
- --This rule flags property names and global variables that are mentioned only once, but where -a different capitalization of the same name is used in multiple other places, suggesting a typo. -
- -
-Check whether the name has been misspelled. If the name is correct, consider using
-a JSLint-style
-/*property ...*/ directive to document the existence of this property,
-or provide an externs file declaring the property.
-
-The following code snippet contains two uses of the log method, but only
-one use of the Log method. This suggests that Log may be a typo
-for log.
-
-If the use of Log is, in fact, a typo, it should be corrected. Otherwise, a
-properties directive can be introduced to document the fact that both
-log and Log properties exist:
-
-Non-standard JSDoc tags are undesirable, since JSDoc-processing tools will either ignore -them or treat them as plain text. -
- --Check whether the tag name is misspelled, or consult the JSDoc documentation to find out -what standard tags are available. -
- -
-In the following example, the constructor Message has a JSDoc comment describing
-its parameters, but the second @param tag has been misspelled as
-@parma.
-
-JSLint directives must not start with a space. For example, /* global window*/
-is not a valid directive, and will not be recognized by JSLint.
-
-Remove the space: /*global window*/.
-
-JSLint directives must consist of a comma-separated list of flags, where each flag -can optionally be followed by a colon and a value. The value may either be a number -or a Boolean (that is, 'true' or 'false'). Directives must not contain other -characters such as '*', which some editors may automatically insert after every line -break when editing a block comment. -
- --Insert commas where necessary and remove stray characters. -
- -
-For example, /*jslint nomen:true vars:true*/ is not a well-formed
-JSLint directive; it should be replaced by /*jslint nomen:true, vars:true*/.
-
-This is another example of a malformed JSLint directive: -
- --It should be fixed as follows: -
- -
-HTML comments are a technique for hiding JavaScript code from browsers that do not interpret script
-tags. Since all popular browsers have supported script tags for many years, this precaution is
-not needed any more.
-
-Remove all HTML comments. -
- -
-The following code block uses HTML comments to hide the script block from ancient browsers.
-
-Since such browsers are no longer widely used, the comments should be removed: -
- --Multi-line string literals are not supported on all platforms, and thus should be avoided. -
- -
-Replace multi-line string literals by multiple strings concatenated with the + operator.
-
-The following example contains a string literal spanning three lines: -
- --It should be rewritten like this: -
- -
-Integer literals starting with the digit 0 may be interpreted as octal numbers by some platforms
-but not others, and thus should be avoided. This does not make a difference for the literal 0
-itself.
-
-If the literal was meant to be octal, convert it to a decimal or hexadecimal number. Otherwise, remove -the leading zero. -
- -
-The following example uses the literal 012, which some platforms will interpret as an octal
-encoding of the decimal number 10, while others will interpret it as the decimal number
-12. Depending on the desired interpretation, it should be replaced with either 10
-or 12.
-
-The ECMAScript standard defines a list of future keywords that should not be used as identifiers. -While they may be accepted by current implementations, they may no longer be supported in the future, -so it is best not to rely on them. -
- --Rename the identifier in question. -
- -
-In the following code snippet, package is used as a variable name. Since package
-is a future reserved word, the variable should be renamed, for instance to pkg.
-
-The ECMAScript standard allows trailing commas in array and object literals which are ignored. However, -older versions of Internet Explorer do not recognize this syntax. Moreover, it can lead to confusion -when used in array literals, since spurious commas other than the last one are not ignored but give rise -to additional undefined array elements. For these reasons, trailing commas should always be avoided. -
- --Remove the trailing comma. -
- --The following code snippet shows an object literal with a trailing comma, which should be removed. -
- -
-On some platforms, the builtin function parseInt parses strings starting with the digit
-0 as octal values (unless an explicit radix is provided). This can lead to unexpected
-results when parsing decimal numbers that may be zero-padded, such as dates.
-
-Provide an explicit radix as the second parameter to parseInt.
-
-In the following example, parseInt is used to convert the contents of a field in an HTML
-form to a number:
-
-Now assume that a user has entered a zero-padded decimal number, say 09, into the form.
-Since the first digit is a zero, older versions of parseInt interpret this value as an
-octal number. When they then encounter 9 (which is not an octal digit), they will stop
-parsing and discard the rest of the string, returning the value 0, which is probably not
-what was expected.
-
-To avoid this problem, an explicit radix parameter should be parsed as follows: -
- -