question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

WebStorm Inspectors (rollup)

See original GitHub issue

Assignment issues

  • 1. Assignment replaceable with operator assignment (operator-assignment) This inspection reports instances of assignment operations in JavaScript content which can be replaced by operator-assignment. Code using operator assignment may be clearer, and theoretically more performant.
  • 2. Assignment to for loop parameter This inspection reports any instances of assignment to a variable declared as a JavaScript for loop parameter. While occasionally intended, this construct can be extremely confusing, and is often the result of a programmer error.
  • 3. Assignment to function parameter (no-param-reassign) This inspection reports any instances of assignment to a variable declared as a JavaScript function parameter. It also reports any attempt to increment or decrement the variable. While occasionally intended, this construct can be extremely confusing, and is often the result of a programmer error.
  • 4. Nested assignment This inspection reports any instances of JavaScript assignment expressions nested inside other expressions. While admirably terse, such expressions may be confusing, and violate the general design principle that a given construct should do precisely one thing.
  • 5. Result of assignment used (no-cond-assign) This inspection reports assignment expressions where the result of the assignment is used in a containing expression. Such assignments are often indications of coding errors such as using = instead of ==. Moreover, they can result in confusion due to order of operations, as evaluation of the assignment may effect the outer expression in unexpected ways.
  • 6. Variable is assigned to itself This inspection reports any assignments of the form x = x in JavaScript content. These are pointless, and usually indicate programmer error.

Bitwise operation issues

  • 7. Bitwise operator usage (no-bitwise) This inspection reports suspicious usages of bitwise AND (“&”) and OR (“|”) operators.
  • 8. Incompatible bitwise mask operation This inspection reports any instances of JavaScript bitwise mask expressions which are guaranteed to evaluate to true or false in JavaScript code. Expressions checked are of the form (var & constant1) == constant2 or (var | constant1) == constant2, where constant1 and constant2 are incompatible bitmask constants.
  • 9. Pointless bitwise expression This inspection reports any instances of pointless bitwise expressions in JavaScript. Such expressions include anding with zero, oring by zero, and shift by zero. Such expressions may be the result of automated refactorings not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.
  • 10. Shift operation by inappropriate constant This inspection reports any instances of JavaScript shift operations where the value shifted by is constant and outside of the reasonable range. Integer shift operations outside of the range 0…31 are reported. Shifting by negative or overly large values is almost certainly a coding error.

Code style issues

  • 11. Chained equality This inspection reports any instances of chained equality comparisons (i.e. a==b==c) in JavaScript code. Such comparisons are confusing.
  • 12. Chained function call This inspection reports any JavaScript function calls whose target is another function call.
  • 13. Constant on left side of comparison (yoda) This inspection reports on comparison operations with constant values on their left-hand side. Some coding conventions specify that constants should be on the right-hand side of comparisons.
  • 14. Constant on right side of comparison (yoda) This inspection reports on comparison operations with constant values on their right-hand side. Some coding conventions specify that constants should be on the left-hand side of comparisons.
  • 15. Nested function call This inspection reports any JavaScript function calls used as arguments to another function call.
  • 16. Non-block statement body (curly) This inspection reports instances of JavaScript if, while, for, and with statements whose bodies are not block statements. While such statements are legal JavaScript, it is usually safer for downstream maintenance to use the code blocks for statement bodies.
  • 17. Undefined property assignment (N/A out of scope) This inspection reports assignments to undefined properties of explicitly type-annotated variables.
  • 18. Unterminated statement (semi) This inspection reports JavaScript statements which are not terminated by a semicolon. While line-breaks may be used instead of semicolons to terminate JavaScript statements, some coding styles prefer the semicolon for consistency with the other languages.
  • 19. Variable declarations are at the scope start (no-inner-declarations) This inspection checks that all local variables declarations are at the beginning of the current function.

Control flow issues

  • 20. break statement This inspection reports any break statements in Javascript content. break statements that end case blocks are not reported.

  • 21. break statement with label (no-label) This inspection reports any labeled break statements in Javascript content.

  • 22. Conditional expression with identical branches This inspection reports any instances of ternary conditional expressions with identical “then” and “else” branches in JavaScript content. Such statements are almost certainly programmer error.

  • 23. Constant conditional expression (no-constant-condition) This inspection reports any instances of conditional expressions of the form true?result1:result2 or false?result1:result2. These expressions sometimes occur as the result of automatic refactoring, and may obviously be simplified.

  • 24. Constant if statement (no-constant-condition) This inspection reports any instances of JavaScript if statements of the form if(true)... or if(false).... These statements sometimes occur due to automatic refactoring, and may obviously be simplified.

  • 25. continue statement (#1945) This inspection reports any continue statements in Javascript content.

  • 26. continue statement with label (no-labels) This inspection reports any labelled continue statements in Javascript content.

  • 27. default not last case in switch This inspection reports any instances of JavaScript switch statements where the default case comes before some other case. This construct is unnecessarily confusing.

  • 28. Duplicate condition in if statement This inspection reports on any duplicate conditions among different branches of an if statement in JavaScript content. While it may rarely be the desired semantics, duplicate conditions usually represent programmer oversight.

  • 29. Fall-through in switch statement (no-fallthrough) This inspection reports any cases where control can proceed from one branch of a switch statement to the next, in Javascript content. Such “fall-through” is often a result of programmer error.

  • 30. for loop may be replaced by while loop This inspection reports any instances of JavaScript for loops which contain neither initialization or update components, and can thus be replaced by simpler while statements.

  • 31. if statement with identical branches This inspection reports any instances of if statements with identical then and else branches in JavaScript content. Such statements are almost certainly programmer error.

  • 32. if statement with too many branches This inspection reports instances of if statements with too many branches in Javascript content. Such statements may be confusing, and are often the sign of inadequate levels of design abstraction. Use the field below to specify the maximum number of branches expected.

  • 33. Labeled statement (no-labels) This inspection reports any labeled statements in Javascript content.

  • 34. Loop statement that doesn’t loop This inspection reports any instance of for, while and do statements in JavaScript content whose bodies are guaranteed to execute at most once. Normally, this is an indication of a bug. Powered by InspectionJS

  • 35. Nested switch statement This inspection reports any switch statements in Javascript content which are nested in other switch statements. Such nested switch statements can be very confusing, particularly if proper indenting is not followed.

  • 36. Pointless boolean expression This inspection reports any instances of pointless or pointlessly complicated boolean expressions in JavaScript content. Such expressions include anding with true, oring with false, equality comparison with a boolean literal, or negation of a boolean literal. Such expressions may be the result of automated refactoring not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.

  • 37. Redundant if statement This inspection reports instances of JavaScript if statements which can be simplified to single assignment or return statements. For example:

    if(foo())
    {
    return true;
    }
    else
    {
    return false;
    }
    can be simplified to
    return foo();
    
  • 38. Redundant conditional expression This inspection reports any instances of JavaScript conditional expressions of the form condition?true:false or condition?false:true. These expressions may be safely simplified to condition or !condition , respectively.

  • 39. switch statement with no default branch (default-case) This inspection reports any switch statements in Javascript content which lack default branches. Such statements may result in difficult bugs, if unexpected cases are silently ignored

  • 40. Tail recursion This inspection reports any instances of tail recursion, that is when a JavaScript function calls itself as its last action before returning. Tail recursion can always be replaced by looping, which will be considerably faster. Some JavaScript engines perform this optimization, while others do not. Thus, tail recursive solutions may have considerably different performance characteristics on different environments.

  • 41. Unnecessary continue statement This inspection reports on any unnecessary continue statements at the end of loops, in JavaScript content. These statements may be safely removed.

  • 42. Unnecessary return statement This inspection reports on any unnecessary return statements in JavaScript functions. Unnecessary return statements are those which return no value and occur just before the function would have “fallen through” to the bottom. These statements may be safely removed.

  • 43. Unnecessary label This inspection reports any instances of unused labels in JavaScript code.

  • 44. Unnecessary label on break statement This inspection reports any labeled break statements in Javascript content whose labels may be removed without changing the flow of control.

  • 45. Unnecessary label on continue statement This inspection reports any labeled continue statements in Javascript content whose labels may be removed without changing the flow of control.

Data flow issues

  • 46. Redundant local variable This inspection reports any instances of unnecessary JavaScript local variables, which add nothing to the comprehensibility of a function. Variables caught include local variables which are immediately returned, local variables that are immediately assigned to another variable and then not used, and local variables which always have the same value as another local variable or parameter.
  • 47. Reuse of local variable (no-redeclare???) This inspection reports any instances where JavaScript local variables are “reused”, overwriting their values with new values unrelated to their original use. Such local variable reuse may be confusing, as the intended semantics of the local variable may vary with each use. It may also be prone to bugs, if code changes result in values that were thought to be overwritten actually being live. It is good practices to keep variable lifetimes as short as possible, and not reuse local variables for the sake of brevity.

DOM issues

  • 48. Call to document.write() This inspection reports JavaScript method calls to document.write() or document.writeln(). Most uses of these calls are better performed using explicit DOM calls such as getElementByID() and createElement(). Additionally, the write() and writeln() calls will not work with XML DOMs, including DOMs for XHTML if viewed as XML. This can result in difficulty to point out bugs.
  • 49. Platform detection This inspection reports common JavaScript patterns for detecting the browser or operating system in which script is being run. In addition to pointing out non-portable constructs, these platform detection patterns are often incomplete and easily fooled. For most cases, detection of individual environment features is preferable to attempting to detect the entire platform. Patterns detected include document.all, document.layers, navigator.userAgent, navigator.oscpu, navigator.appName, navigator.appCodeName, and navigator.platform
  • 50. Use of innerHTML property This inspection reports JavaScript accesses to DOM nodes as text using the innerHTML property. Most uses of innerHTML are better performed using explicit DOM calls such as getElementByID() and createElement(). Additionally, innerHTML will not work with XML DOMs, including DOMs for XHTML if viewed as XML. This can lead to difficult to diagnose bugs.
  • 51. XHTML incompatibilities This inspection reports common JavaScript DOM patterns which may present problems with XHTML documents. In particular, the patterns detected will behave completely differently depending on whether the document is loaded as XML or HTML. This can result in subtle bugs where script behavior is dependent on the MIME-type of the document, rather than its content. Patterns detected include document.body, document.images, document.applets, document.links, document.forms, and document.anchors.

Error handling

  • 52. continue or break inside finally block This inspection reports any instances of break or continue statements inside of finally blocks. While occasionally intended, such statements are very confusing, may mask exceptions thrown, and tremendously complicate debugging.
  • 53. Empty catch block (no-empty) This inspection reports any empty catch blocks in Javascript content. Empty catch blocks are a sign that errors are simply being ignored, rather than properly handled.
  • 54. Empty finally block (no-empty) This inspection reports any empty finally blocks in Javascript content. Empty finally are usually the result of a coding error.
  • 55. Empty try block (no-empty) This inspection reports any empty try blocks in Javascript content. Empty try is usually the result of a coding error.
  • 56. Exception used for local control-flow This inspection reports any instances of JavaScript throw statements whose exceptions are always caught by containing try statements. Using throw statements as a goto to change the local flow of control is likely to be confusing.
  • 57. return inside finally block This inspection reports any instances of return statements inside of finally blocks in JavaScript content. While occasionally intended, such return statements may mask exceptions thrown, and tremendously complicate debugging.
  • 58. throw inside finally block This inspection reports any instances of throw statements inside of finally blocks. While occasionally intended, such throw statements may mask exceptions thrown, and tremendously complicate debugging.
  • 59. Unused catch parameter (no-unused) This inspection reports any JavaScript catch parameters that are unused in their corresponding blocks. This inspection will not report any catch parameters named “ignore” or “ignored”.

General

  • 60. Closure compiler syntax (N/A Framework specific rule) Checks code for warnings implied by Google Closure Compiler annotations. This includes correct usage of @interface and @implements tags.
  • 61. Deprecated JavaScript symbol Checks for using deprecated JavaScript functions and variables.
  • 62. Duplicate JavaScript declaration (no-redeclare) Checks JavaScript declaration to be declared once in current scope.
  • 63. Implicitly declared global JavaScript variable (no-undef) Checks JavaScript variables to be declared explicitly with var statement.
  • 64. jQuery usage efficiency (N/A Framework specific rule) Checks that jQuery selectors are used in an efficient way. It suggests to split descendant selectors which are prefaced with ID selector and warns about duplicated selectors which could be cached.
  • 65. JSDoc comment matches function signature (valid-jsdoc) Checks that parameters defined within JSDoc comment match function’s actual parameters, i.e. have the same names and quantity.
  • 66. Last comma in array literal (no-comma-dangle) Checks JavaScript source code for last comma in array literal. Such array has different length among different browsers.
  • 67. Last comma in object literal (no-comma-dangle) Checks JavaScript source code for last comma in object literal. Such object could have problem in certain JavaScript engine implementations.
  • 68. Method can be static (N/A Language specific rule) Checks for ActionScript and TypeScript functions that can be static.
  • 69. Mismatched query and update of collection This inspection reports collection fields or variables whose contents are either queried and not updated, or updated and not queried. Such mismatched queries and updates are pointless, and may indicate either dead code or a typographical error. Use the tables below to specify which methods are update and/or query methods. The names are matched with the beginning of the method name. Query methods which return their result are automatically detected, only query methods which return their result in an argument need to be specified.
  • 70. Possibly incorrect target of indexed property access This inspection reports JavaScript potentially invalid indexed property access such as Array[1].
  • 71. Potentially invalid constructor usage This inspection reports JavaScript potentially invalid constructor function usages such as: using non constructor in new, using constructor’s prototype, report constructor call without new. Constructor function assumed to have upper case name (optional) or have explicit JSDoc @constructor tag.
  • 72. Potentially invalid reference to ‘this’ from closure (Annoying, doesn’t work all that well) Checks for JavaScript this to be the same in closure and in outer context.
  • 73. Primitive type object wrapper used (no-new-wrapper) Checks for improper usage of wrappers for JavaScript primitive types. Also, warning will be produced when property of primitive type is modified, as assigned value will be lost.
  • 74. @private and @protected members accessibility (N/A typed) This inspection checks that JavaScript members marked with @private and @protected tags are visible in current context.
  • 75. Referencing mutable variable from closure Checks for accessing mutable JavaScript variables in nested functions.
  • 76. Signature mismatch (N/A typed) Checks JavaScript called function arguments, return values, assigned expressions to be of correct type.
  • 77. Suspicious name combination Reports assignments and function calls where the name of the variable to which a value is assigned or the function parameter does not seem to match the name of the value assigned to it. For example: var x = 0; var y = x; or var x = 0, y = 0; var rc = new Rectangle(y, x, 20, 20); the error is reported if the parameter name or assignment target name contains words from one group and the name of the assigned or passed variable contains words from a different group.
  • 78. There is no locally stored library for the HTTP link. (N/A) Checks that URL of an external JavaScript library is associated with a locally stored file used for code completion and navigation. Use ‘Download library’ quick fix (Alt+Enter) to solve the problem.
  • 79. Type mismatch (N/A typed) Checks JavaScript called function parameters, return values, assigned expressions to be of correct type.
  • 80. Unfiltered for..in loop (guard-for-in) Checks for any instances of unfiltered for-in loops in JavaScript. The use of this construct results in processing inherited or unexpected properties. You need to filter own properties with hasOwnProperty() method.
  • 81. Unnecessary semicolon (no-extra-semi) Checks JavaScript source code for unneeded semicolons.
  • 82. Unresolved JavaScript function (no-undef???) Checks JavaScript called functions to be valid ones.
  • 83. Unresolved JavaScript variable (no-undef???) Checks JavaScript referenced variables and fields to be valid ones.
  • 84. Unused JavaScript / ActionScript assignment Checks JavaScript / ActionScript for unused assignments.
  • 85. Unused JavaScript / ActionScript global symbol Checks if JavaScript / ActionScript public functions, variables, classes, and properties are used in global scope.
  • 86. Unused JavaScript / ActionScript local symbol (no-unused-vars) Checks JavaScript / ActionScript parameter, local variable, function, classes and private member declarations to be used in given file scope.
  • 87. Validate JSDoc / ASDoc (valid-jsdoc) This inspection validates references in JavaScript / ActionScript documentation comments (JSDoc / ASDoc).
  • 88. Validate JSON (N/A JSON validation) This inspection checks that *.json files comply with JSON specification.

JavaScript function metrics

  • 89. Function with more than three negations This inspection reports JavaScript functions with three or more negation operations ( ! or !=). Such functions may be unnecessarily confusing.
  • 90. Function with multiple loops This inspection reports any instances of JavaScript functions containing multiple loop statements.
  • 91. Function with multiple return points This inspection reports any instances of JavaScript functions have multiple return points. Some coding standards warn against functions with multiple returns, as they may make functions more difficult to understand and maintain.
  • 92. Function with too many parameters (max-params) This inspection reports any instances of JavaScript functions with too many parameters. Functions with too many parameters are often an indication of design weakness.
  • 93. Overly complex function (complexity) This inspection reports any instances of JavaScript functions that have too high a cyclomatic complexity. Cyclomatic complexity is basically a measurement of the number of branching points in a function. Functions with too high a cyclomatic complexity may be confusing and difficult to test.
  • 94. Overly long function (max-statements) This inspection reports any instances of overly long JavaScript functions. Function length is calculated by counting up the number of non-empty statements in the function. Functions that are too long are error-prone, and difficult to test.
  • 95. Overly nested function (max-depth) This inspection reports any instances of JavaScript functions whose bodies are contain statements too deeply nested within other statements. Functions with too much statement nesting may be confusing, and are a good sign that refactoring may be necessary.

JavaScript validity issues

  • 96. debugger statement (no-debugger) This inspection reports JavaScript debugger statements, used for interaction with Javascript debuggers. Such statements should probably not be found in production code.
  • 97. Duplicate case label (no-duplicate-case) This inspection reports any duplicated case labels on JavaScript switch statements. Such switch statements are normally an indication of programmer error.
  • 98. Expression statement which is not assignment or call (no-unused-expressions) This inspection reports expression statements which are not assignments or calls. Such statements have no dubious semantics, are normally the result of programmer error.
  • 99. Function with inconsistent returns (consistent-return) This inspection reports any instances of JavaScript functions which return a value in some circumstances and return without a value in others. While legal, such code almost certainly represents a programming error
  • 100. Reserved word used as name This inspection reports on any uses of JavaScript reserved words being used as a name. The JavaScript specification reserves a number of words which are currently not used as JavaScript keywords. Using those words as identifiers may result in broken code if later versions of JavaScript use them as keywords.
  • 101. String literal which breaks HTML parsing This inspection reports any instances of JavaScript string literals which contain the sequence ‘</’. Such strings are legal JavaScript, but may result in incorrect parsing of any HTML the JavaScript is embedded in.
  • 102. ‘this’ expression which references the global object This inspection reports instances of JavaScript this expression occurring outside of object literals or constructor bodies. Such this expressions are legal JavaScript, and reference the top-level “global” JavaScript object, but are largely useless.
  • 103. Unreachable code (no-unreachable) This inspection reports any instances of JavaScript code which can never be executed. Such code almost certainly represents a programming error

Naming conventions

  • 104. Function naming convention This inspection reports instances of JavaScript functions whose names are either too short, too long, or do not follow the specified regular expression pattern. Use the fields provided below to specify mininum length, maximum length and regular expression expected for local variables names.
  • 105. Function parameter naming convention This inspection reports instances of JavaScript function parameters whose names are either too short, too long, or do not follow the specified regular expression pattern. Use the fields provided below to specify mininum length, maximum length and regular expression expected for local variables names.
  • 106. Local variable naming convention This inspection reports instances of JavaScript local variables whose names are either too short, too long, or do not follow the specified regular expression pattern. Use the fields provided below to specify mininum length, maximum length and regular expression expected for local variables names.

Potentially confusing code constructs

  • 107. Anonymous function (func-names) This inspection reports anonymous JavaScript functions. While often very handy, anonymous functions may be confusing, and are discouraged in some coding standards.
  • 108. Comma expression (#561) This inspection reports any instances of JavaScript comma expressions. Comma expressions are often a sign of overly clever code, and may lead to subtle bugs. Comma expressions in the initializer or update section of a for loop are ignored by this inspection.
  • 109. Conditional expression (no-ternary) This inspection reports ternary conditional expressions. Some coding standards prohibit such expressions, in favor of explicit if statements.
  • 110. Confusing floating point literal (no-floating-decimal) This inspection reports any JavaScript floating point numbers which do not have a decimal point, numbers before the decimal point, and numbers after the decimal point. Such literals may be confusing, and violate several coding standards.
  • 111. Confusing sequence of ‘+’ or ‘-’ This inspection reports any suspicions combinations of + or - characters in JavaScript code (e.g. a+++b. While legal, such sequences are confusing, and may have their semantics changed through changes in whitespace.
  • 112. Execution of dynamically generated JavaScript (no-eval) This inspection reports on any uses of the eval ,setTimeout, setInterval functions, or allocation of a Function object in JavaScript. These functions are used to execute arbitrary strings of JavaScript text, often dynamically generated. This can be very confusing, and may be a security risk.
  • 113. Magic number This inspection reports all instances of “magic numbers”, literal numeric constants used without declaration, used in JavaScript code. “Magic numbers” can result in code whose intention is extremely unclear, and may result in errors if a “magic number” is changed in one code location but not another. The numbers 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 0.0 and 1.0 are not reported by this inspection.
  • 114. Negated if statement This inspection reports any instances of if statements in JavaScript content which contain else branches and whose conditions are negated. Flipping the order of the if and else branches will usually increase the clarity of such statements.
  • 115. Negated conditional expression This inspection reports any instances of conditional expressions in JavaScript content whose conditions are negated. Flipping the order of the conditional expression branches will usually increase the clarity of such statements.
  • 116. Nested conditional expression (no-nested-ternary) This inspection reports ternary conditional expressions contained within other ternary conditions. Such nested conditionals may be extremely confusing, and best replaced by more explicit conditional logic.
  • 117. Nested function This inspection reports JavaScript functions nested inside other functions. While JavaScript allows functions to be nested, such constructs may be confusing. Additionally, nested functions are prone to cause difficult-to-diagnose memory leaks in certain browsers, including Microsoft Internet Explorer.
  • 118. Octal Integer (no-octal) This inspection reports any instances of octal integer literals in JavaScript code. Some coding standards prohibit the use of octal literals, as they may be easily confused with decimal literals.
  • 119. Overly complex arithmetic expression This inspection reports any instances of JavaScript arithmetic expressions with too many terms. Such expressions may be confusing and bug-prone. Use the field provided below to specify the maximum number of terms allowed in an arithmetic expression.
  • 120. Overly complex boolean expression This inspection reports any instances of JavaScript boolean expressions with too many terms. Such expressions may be confusing and bug-prone. Use the field provided below to specify the maximum number of terms allowed in an arithmetic expression.
  • 121. Pointless arithmetic expression This inspection reports any instances of pointless arithmetic expressions in JavaScript content. Such expressions include adding or subtracting zero, multiplying by zero or one, division by one, and shift by zero. Such expressions may be the result of automated refactoring not completely followed through to completion, and in any case are unlikely to be what the developer intended to do.
  • 131. Result of increment or decrement used (no-plusplus) This inspection reports increment (++) or decrement (--) expressions where the result of the assignment is used in a containing expression. Such assignments can result in confusion due to order of operations, as evaluation of the assignment may effect the outer expression in unexpected ways.
  • 132. Statement with empty body (no-empty) This inspection reports instances of JavaScript if, while, for, and with statements whose bodies are empty. While occasionally useful, such statements are often the result of typos, and may cause confusion.
  • 133. Unnecessary block statement (no-lone-lblocks) This inspection reports unnecessary block statements in JavaScript content. Block statements that are not used as the body of if, for, while, do, with, or try statements, or as the body of a function declaration are reported. Since JavaScript blocks do not introduce new scopes as is common in Java and other languages, free-standing block statements may be the result of code confusion, and may result in subtle bugs.
  • 134. Use of caller property (no-caller) This inspection reports on any uses of the caller property in a JavaScript function. Use of this property to access the stack frame of the calling method can be extremely confusing, and result in subtle bugs.
  • 135. void expression (no-void) This inspection reports any void expressions in JavaScript statements. Since void behaves completely differently in JavaScript and Java, these expressions maybe confusing.
  • 136. with statement (no-with) This inspection reports any with statements in Javascript content. with statements result in potentially confusing implicit bindings, and may behave strangely in setting new variables.

Probable bugs

  • 137. Comparison with NaN (use-isnan) Checks code for comparisons with NaN. Comparisons like expr == NaN or expr === NaN are always evaluated to false.

  • 138. Consecutive commas in array literal (no-sparse-arrays) Checks that array literal doesn’t contain consecutive commas. Skipped element takes undefined value, but it could be done unintendedly, e.g. when commas are at the end of one line and at the beginning of the following.

  • 139. Constructor returns primitive value Checks that function recognized as constructor does not return primitive values. When called with new, this value will be lost and object will be returned instead. To avoid warnings, you can explicitly specify function’s return type with @return tag.

  • 140. Divide by zero This inspection reports any instances of division by zero or remainder by zero in JavaScript code.

  • 141. Equality comparison which may cause unexpected coercion This inspection reports on any JavaScript equality comparisons which may cause unexpected type coercions. In JavaScript, == and != cause type coercions, which can cause unexpected evaluations (e.g. 0 == false = true. == or != comparisions to 0, '', null, true, false, or undefined will be flagged by this inspection.

  • 142. for loop where update or condition does not use loop variable This inspection reports any instances of JavaScript for loops where the condition or update does not use the for loop variable.

  • 143. Infinite loop statement This inspection reports any instances of for, while, or do statements which can only exit by throwing an exception. While such statements may be correct, they are often a symptom of coding errors.

  • 144. Infinite recursion This inspection reports any instances of JavaScript functions which must either recurse infinitely or throw an exception. functions reported by this inspection can not return normally.

  • 145. Non short-circuit boolean expression This inspection reports on any uses in JavaScript code of the non-short-circuit forms of boolean and and or ( & and |). The non-short-circuit versions are occasionally useful, but their presence is often due to typos of the short-circuit forms ( && and || ), and may lead to subtle bugs.

  • 146. Result of object allocation ignored (no-new) This inspection reports any instances of JavaScript object allocation where the object allocated ignored. Such allocation expressions are legal JavaScript, but are usually either inadvertent, or evidence of a very odd object initialization strategy.

  • 147. Text label in switch statement This inspection reports any instances of labeled statements inside of JavaScript switch statements. While occasionally intended, this construction is often the result of a typo.

    switch(x)
    {
    case 1:
    case2: //typo!
    case 3:
    break;
    }
    

<bountysource-plugin>

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource. </bountysource-plugin>

Issue Analytics

  • State:closed
  • Created 10 years ago
  • Comments:22 (18 by maintainers)

github_iconTop GitHub Comments

1reaction
Protectedcommented, Mar 8, 2014

Damn it, people, stop writing @protected in comments or commit notes!

0reactions
nzakascommented, Jun 25, 2016

We’ve had this item for two years and I don’t see us working down this list any further, so closing. Please file individual issues if there are rules on this list that you’d like to request.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Disabling and enabling inspections - WebStorm - JetBrains
Some inspections may report problems that you currently do not want to see. In this case, you can disable or suppress them.
Read more >
Setting up Your Development Environment | Getting Started
If you're developing with an IDE from JetBrains with JavaScript Support (e.g. WebStorm) or Visual Studio Code, we recommend to always use the...
Read more >
Plugins - Cypress Documentation
Watches and bundles your spec files via Rollup. #rollup ... Cypress preprocessor for bundling JavaScript via rollup. #rollup ... cypress-layout-inspector.
Read more >
VSCode for WebStorm Users - boneskull dot com
VSCode is generally faster and more responsive than WebStorm; VSCode's JavaScript inspection/completion experience is just plain better; Free as ...
Read more >
Webpack vs WebStorm | What are the differences? - StackShare
Through "loaders" modules can be CommonJs, AMD, ES6 modules, CSS, Images, JSON, Coffeescript, LESS, ... and your custom stuff; WebStorm: The smartest JavaScript ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found