cBioPortal/iViz

View on GitHub

Showing 1,095 of 1,095 total issues

Line 296 exceeds the maximum line length of 80.
Open

                              window.cbioURL + 'study?id=' + self_.savedVC.id + '\')">' +

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Strings must use singlequote.
Open

                document.execCommand("copy");

Enforce Quote Style (quotes)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

JavaScript allows you to define strings in one of three ways: double quotes, single quotes, and backticks (as of ECMAScript 6). For example:

/*eslint-env es6*/

var double = "double";
var single = 'single';
var backtick = `backtick`;    // ES6 only

Each of these lines creates a string and, in some cases, can be used interchangeably. The choice of how to define strings in a codebase is a stylistic one outside of template literals (which allow embedded of expressions to be interpreted).

Many codebases require strings to be defined in a consistent manner.

Rule Details

This rule is aimed at ensuring consistency of string quotes and as such will report a problem when an inconsistent style is found.

The rule configuration takes up to two options:

  1. The first option is "double", "single" or "backtick" for double-quotes, single-quotes or backticks respectively. The default is "double".
  2. The second option takes two options:
    1. "avoidEscape": When using "avoidEscape", this rule will not report a problem when a string is using single-quotes or double-quotes so long as the string contains a quote that would have to be escaped otherwise. For example, if you specify "double" and "avoidEscape", the string 'He said, "hi!"' is not considered a problem because using double quotes for that string would require escaping the double quotes inside of the string. This option is off by default.
    2. "allowTemplateLiterals": when using "allowTemplateLiterals", this rule will not report a problem when a string is using backticks and option one is either "double" or "single".

When using "single" or "double", template literals that don't contain a substitution, don't contain a line break and aren't tagged templates, are flagged as problems, even with the "avoidEscape" option. However they are not problems when "allowTemplateLiterals" is used.

Configuration looks like this:

[2, "single", {"avoidEscape": true, "allowTemplateLiterals": true}]

Deprecation notice: The avoid-escape option is a deprecated syntax and you should use the object form instead.

The following patterns are considered problems:

/*eslint quotes: ["error", "double"]*/

var single = 'single';
var unescaped = 'a string containing "double" quotes';
/*eslint quotes: ["error", "single"]*/

var double = "double";
var unescaped = "a string containing 'single' quotes";
/*eslint quotes: ["error", "double", {"avoidEscape": true}]*/

var single = 'single';
var single = `single`;
/*eslint quotes: ["error", "single", {"avoidEscape": true}]*/

var double = "double";
var double = `double`;
/*eslint quotes: ["error", "backtick"]*/

var single = 'single';
var double = "double";
var unescaped = 'a string containing `backticks`';
/*eslint quotes: ["error", "backtick", {"avoidEscape": true}]*/

var single = 'single';
var double = "double";

The following patterns are not considered problems:

/*eslint quotes: ["error", "double"]*/
/*eslint-env es6*/

var double = "double";
var backtick = `back\ntick`;  // backticks are allowed due to newline
var backtick = tag`backtick`; // backticks are allowed due to tag
/*eslint quotes: ["error", "single"]*/
/*eslint-env es6*/

var single = 'single';
var backtick = `back${x}tick`; // backticks are allowed due to substitution
/*eslint quotes: ["error", "double", {"avoidEscape": true}]*/

var single = 'a string containing "double" quotes';
/*eslint quotes: ["error", "single", {"avoidEscape": true}]*/

var double = "a string containing 'single' quotes";
/*eslint quotes: ["error", "double", {"allowTemplateLiterals": true}]*/

var single = 'single';
var single = `single`;
/*eslint quotes: ["error", "single", {"allowTemplateLiterals": true}]*/

var double = "double";
var double = `double`;
/*eslint quotes: ["error", "backtick"]*/
/*eslint-env es6*/

var backtick = `backtick`;
/*eslint quotes: ["error", "backtick", {"avoidEscape": true}]*/

var double = "a string containing `backtick` quotes"

When Not To Use It

If you do not need consistency in your string styles, you can safely disable this rule. Source: http://eslint.org/docs/rules/

Line 333 exceeds the maximum line length of 80.
Open

              var caseIndex = self_.getCaseIndex(type, _dataObj.study_id, _dataObj[idType]);
Severity: Minor
Found in app/scripts/main.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Line 352 exceeds the maximum line length of 80.
Open

              && ['CANCER_TYPE', 'CANCER_TYPE_DETAILED'].indexOf(_attrId) === -1) {
Severity: Minor
Found in app/scripts/main.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

'&&' should be placed at the end of the line.
Open

              && ['CANCER_TYPE', 'CANCER_TYPE_DETAILED'].indexOf(_attrId) === -1) {
Severity: Minor
Found in app/scripts/main.js by eslint

Operator Linebreak (operator-linebreak)

When a statement is too long to fit on a single line, line breaks are generally inserted next to the operators separating expressions. The first style coming to mind would be to place the operator at the end of the line, following the english punctuation rules.

var fullHeight = borderTop +
                 innerHeight +
                 borderBottom;

Some developers find that placing operators at the beginning of the line makes the code more readable.

var fullHeight = borderTop
               + innerHeight
               + borderBottom;

Rule Details

The operator-linebreak rule is aimed at enforcing a particular operator line break style. As such, it warns whenever it sees a binary operator or assignment that does not adhere to a particular style: either placing linebreaks after or before the operators.

Options

The rule takes two options, a string, which can be "after", "before" or "none" where the default is "after" and an object for more fine-grained configuration.

You can set the style in configuration like this:

"operator-linebreak": ["error", "before", { "overrides": { "?": "after" } }]

The default configuration is to enforce line breaks after the operator except for the ternary operator ? and : following that.

"after"

This is the default setting for this rule. This option requires the line break to be placed after the operator.

While using this setting, the following patterns are considered problems:

/*eslint operator-linebreak: ["error", "after"]*/

foo = 1
+
2;

foo = 1
    + 2;

foo
    = 5;

if (someCondition
    || otherCondition) {
}

answer = everything
  ? 42
  : foo;

The following patterns are not considered problems:

/*eslint operator-linebreak: ["error", "after"]*/

foo = 1 + 2;

foo = 1 +
      2;

foo =
    5;

if (someCondition ||
    otherCondition) {
}

answer = everything ?
  42 :
  foo;

"before"

This option requires the line break to be placed before the operator.

While using this setting, the following patterns are considered problems:

/*eslint operator-linebreak: ["error", "before"]*/

foo = 1 +
      2;

foo =
    5;

if (someCondition ||
    otherCondition) {
}

answer = everything ?
  42 :
  foo;

The following patterns are not considered problems:

/*eslint operator-linebreak: ["error", "before"]*/

foo = 1 + 2;

foo = 1
    + 2;

foo
    = 5;

if (someCondition
    || otherCondition) {
}

answer = everything
  ? 42
  : foo;

"none"

This option disallows line breaks on either side of the operator.

While using this setting, the following patterns are considered problems:

/*eslint operator-linebreak: ["error", "none"]*/

foo = 1 +
      2;

foo = 1
    + 2;

if (someCondition ||
    otherCondition) {
}

if (someCondition
    || otherCondition) {
}

answer = everything
  ? 42
  : foo;

answer = everything ?
  42 :
  foo;

The following patterns are not considered problems:

/*eslint operator-linebreak: ["error", "none"]*/

foo = 1 + 2;

foo = 5;

if (someCondition || otherCondition) {
}

answer = everything ? 42 : foo;

Fine-grained control

The rule allows you to have even finer-grained control over individual operators by specifying an overrides dictionary:

"operator-linebreak": ["error", "before", { "overrides": { "?": "after", "+=": "none" } }]

This would override the global setting for that specific operator.

"ignore" override

This option is only supported using overrides and ignores line breaks on either side of the operator.

While using this setting, the following patterns are not considered problems:

/*eslint operator-linebreak: ["error", "after", { "overrides": { "?": "ignore", ":": "ignore"} }]*/

answer = everything ?
  42
  : foo;

answer = everything
  ?
  42
  :
  foo;

When Not To Use It

If your project will not be using a common operator line break style, turn this rule off.

Related Rules

'iViz' is not defined.
Open

              numOfKeys > iViz.opts.pie2TableLimit) {
Severity: Minor
Found in app/scripts/main.js by eslint

Disallow Undeclared Variables (no-undef)

This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer).

Rule Details

Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment.

Examples of incorrect code for this rule:

/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

Examples of correct code for this rule with global declaration:

/*global someFunction b:true*/
/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

The b:true syntax in /*global */ indicates that assignment to b is correct.

Examples of incorrect code for this rule with global declaration:

/*global b*/
/*eslint no-undef: "error"*/

b = 10;

By default, variables declared in /*global */ are read-only, therefore assignment is incorrect.

Options

  • typeof set to true will warn for variables used inside typeof check (Default false).

typeof

Examples of correct code for the default { "typeof": false } option:

/*eslint no-undef: "error"*/

if (typeof UndefinedIdentifier === "undefined") {
    // do something ...
}

You can use this option if you want to prevent typeof check on a variable which has not been declared.

Examples of incorrect code for the { "typeof": true } option:

/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Examples of correct code for the { "typeof": true } option with global declaration:

/*global a*/
/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Environments

For convenience, ESLint provides shortcuts that pre-define global variables exposed by popular libraries and runtime environments. This rule supports these environments, as listed in Specifying Environments. A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

/*eslint no-undef: "error"*/
/*eslint-env browser*/

setTimeout(function() {
    alert("Hello");
});

node

Examples of correct code for this rule with node environment:

/*eslint no-undef: "error"*/
/*eslint-env node*/

var fs = require("fs");
module.exports = function() {
    console.log(fs);
};

When Not To Use It

If explicit declaration of global variables is not to your taste.

Compatibility

This rule provides compatibility with treatment of global variables in JSHint and JSLint.

Further Reading

Line 110 exceeds the maximum line length of 80.
Open

          classes: 'qtip-light qtip-rounded qtip-shadow forceZindex qtip-max-width iviz-pie-qtip iviz-pie-label-qtip'

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Properties shouldn't be quoted as all quotes are redundant.
Open

          tableData_.mutated_genes.allSamples.push({
Severity: Minor
Found in app/scripts/main.js by eslint

Quoting Style for Property Names (quote-props)

Object literal property names can be defined in two ways: using literals or using strings. For example, these two objects are equivalent:

var object1 = {
    property: true
};

var object2 = {
    "property": true
};

In many cases, it doesn't matter if you choose to use an identifier instead of a string or vice-versa. Even so, you might decide to enforce a consistent style in your code.

There are, however, some occasions when you must use quotes:

  1. If you are using an ECMAScript 3 JavaScript engine (such as IE8) and you want to use a keyword (such as if) as a property name. This restriction was removed in ECMAScript 5.
  2. You want to use a non-identifier character in your property name, such as having a property with a space like "one two".

Another example where quotes do matter is when using numeric literals as property keys:

var object = {
    1e2: 1,
    100: 2
};

This may look alright at first sight, but this code in fact throws a syntax error in ECMAScript 5 strict mode. This happens because 1e2 and 100 are coerced into strings before getting used as the property name. Both String(1e2) and String(100) happen to be equal to "100", which causes the "Duplicate data property in object literal not allowed in strict mode" error. Issues like that can be tricky to debug, so some prefer to require quotes around all property names.

Rule Details

This rule aims to enforce use of quotes in property names and as such will flag any properties that don't use quotes (default behavior).

Options

There are four behaviors for this rule: "always" (default), "as-needed", "consistent" and "consistent-as-needed". You can define these options in your configuration as:

{
    "quote-props": ["error", "as-needed"]
}

"always"

When configured with "always" as the first option (the default), quoting for all properties will be enforced. Some believe that ensuring property names in object literals are always wrapped in quotes is generally a good idea, since depending on the property name you may need to quote them anyway. Consider this example:

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

Here, the properties foo and baz are not wrapped in quotes, but qux-lorem is, because it doesn’t work without the quotes. This is rather inconsistent. Instead, you may prefer to quote names of all properties:

var object = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

or, if you prefer single quotes:

var object = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

When configured with "always" as the first option (the default), quoting for all properties will be enforced. The following patterns are considered problems:

/*eslint quote-props: ["error", "always"]*/

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "always"]*/
/*eslint-env es6*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

"as-needed"

When configured with "as-needed" as the first option, quotes will be enforced when they are strictly required, and unnecessary quotes will cause warnings. The following patterns are considered problems:

/*eslint quote-props: ["error", "as-needed"]*/

var object = {
    "a": 0,
    "0": 0,
    "true": 0,
    "null": 0
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "as-needed"]*/
/*eslint-env es6*/

var object1 = {
    "a-b": 0,
    "0x0": 0,
    "1e2": 0
};

var object2 = {
    foo: 'bar',
    baz: 42,
    true: 0,
    0: 0,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

When the "as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords should be quoted as properties. By default it is set to false.

{
    "quote-props": ["error", "as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

Another modifier for this rule is the unnecessary option which defaults to true. Setting this to false will prevent the rule from complaining about unnecessarily quoted properties. This comes in handy when you only care about quoting keywords.

{
    "quote-props": ["error", "as-needed", { "keywords": true, "unnecessary": false }]
}

When unnecessary is set to false, the following patterns stop being problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true, "unnecessary": false }]*/

var x = {
    "while": 1,
    "foo": "bar"  // Would normally have caused a warning
};

A numbers flag, with default value false, can also be used as a modifier for the "as-needed" mode. When it is set to true, numeric literals should always be quoted.

{
    "quote-props": ["error", "as-needed", {"numbers": true}]
}

When numbers is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "numbers": true }]*/

var x = {
    100: 1
}

and the following patterns stop being problems:

var x = {
    "100": 1
}

"consistent"

When configured with "consistent", the patterns below are considered problems. Basically "consistent" means all or no properties are expected to be quoted, in other words quoting style can't be mixed within an object. Please note the latter situation (no quotation at all) isn't always possible as some property names require quoting.

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    baz: 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

var object3 = {
    foo: 'bar',
    baz: 42
};

"consistent-as-needed"

When configured with "consistent-as-needed", the behavior is similar to "consistent" with one difference. Namely, properties' quoting should be consistent (as in "consistent") but whenever all quotes are redundant a warning is raised. In other words if at least one property name has to be quoted (like qux-lorem) then all property names must be quoted, otherwise no properties can be quoted. The following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    foo: 'bar',
    baz: 42
};

When the "consistent-as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords can be used unquoted as properties. By default it is set to false.

{
    "quote-props": ["error", "consistent-as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

When Not To Use It

If you don't care if property names are consistently wrapped in quotes or not, and you don't target legacy ES3 environments, turn this rule off.

Further Reading

Line 443 exceeds the maximum line length of 80.
Open

            "molecularProfileId": window.iviz.datamanager.getMutationProfileIdByStudyId(studyId),
Severity: Minor
Found in app/scripts/main.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Missing JSDoc comment.
Open

    function initReactData() {

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

  • FunctionDeclaration
  • ClassDeclaration
  • MethodDefinition

Options

This rule accepts a require object with its properties as

  • FunctionDeclaration (default: true)
  • ClassDeclaration (default: false)
  • MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

'iViz' is not defined.
Open

      iViz.init(data_, _selectedSamples, _selectedPatients);
Severity: Minor
Found in app/scripts/main.js by eslint

Disallow Undeclared Variables (no-undef)

This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer).

Rule Details

Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment.

Examples of incorrect code for this rule:

/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

Examples of correct code for this rule with global declaration:

/*global someFunction b:true*/
/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

The b:true syntax in /*global */ indicates that assignment to b is correct.

Examples of incorrect code for this rule with global declaration:

/*global b*/
/*eslint no-undef: "error"*/

b = 10;

By default, variables declared in /*global */ are read-only, therefore assignment is incorrect.

Options

  • typeof set to true will warn for variables used inside typeof check (Default false).

typeof

Examples of correct code for the default { "typeof": false } option:

/*eslint no-undef: "error"*/

if (typeof UndefinedIdentifier === "undefined") {
    // do something ...
}

You can use this option if you want to prevent typeof check on a variable which has not been declared.

Examples of incorrect code for the { "typeof": true } option:

/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Examples of correct code for the { "typeof": true } option with global declaration:

/*global a*/
/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Environments

For convenience, ESLint provides shortcuts that pre-define global variables exposed by popular libraries and runtime environments. This rule supports these environments, as listed in Specifying Environments. A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

/*eslint no-undef: "error"*/
/*eslint-env browser*/

setTimeout(function() {
    alert("Hello");
});

node

Examples of correct code for this rule with node environment:

/*eslint no-undef: "error"*/
/*eslint-env node*/

var fs = require("fs");
module.exports = function() {
    console.log(fs);
};

When Not To Use It

If explicit declaration of global variables is not to your taste.

Compatibility

This rule provides compatibility with treatment of global variables in JSHint and JSLint.

Further Reading

Trailing spaces not allowed.
Open

      

Disallow trailing spaces at the end of lines (no-trailing-spaces)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

Sometimes in the course of editing files, you can end up with extra whitespace at the end of lines. These whitespace differences can be picked up by source control systems and flagged as diffs, causing frustration for developers. While this extra whitespace causes no functional issues, many code conventions require that trailing spaces be removed before checkin.

Rule Details

The following patterns are considered problems:

/*eslint no-trailing-spaces: "error"*/

// spaces, tabs and unicode whitespaces
// are not allowed at the end of lines
var foo = 0;//•••••
var baz = 5;//••

The following patterns are not considered problems:

/*eslint no-trailing-spaces: "error"*/

var foo = 0;

var baz = 5;

Options

There is one option for this rule, skipBlankLines. When set to true, the rule will not flag any lines that are made up purely of whitespace. In short, if a line is zero-length after being trimmed of whitespace, then the rule will not flag that line when skipBlankLines is enabled.

You can enable this option in your config like this:

{
    "no-trailing-spaces": ["error", { "skipBlankLines": true }]
}

With this option enabled, The following patterns are not considered problems:

/*eslint no-trailing-spaces: ["error", { "skipBlankLines": true }]*/

var foo = 0;
//••••
var baz = 5;

Source: http://eslint.org/docs/rules/

Line 119 exceeds the maximum line length of 80.
Open

                  _cnaCaseUIDs.push(_studyToSampleToPatientMap[studyId].sample_to_uid[sampleId]);
Severity: Minor
Found in app/scripts/model/dataProxy.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Missing JSDoc comment.
Open

    function pieLabelMouseLeave(data) {

Require JSDoc comment (require-jsdoc)

JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

/**
 * Adds two numbers together.
 * @param {int} num1 The first number.
 * @param {int} num2 The second number.
 * @returns {int} The sum of the two numbers.
 */
function sum(num1, num2) {
    return num1 + num2;
}

Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

Rule Details

This rule generates warnings for nodes that do not have JSDoc comments when they should. Supported nodes:

  • FunctionDeclaration
  • ClassDeclaration
  • MethodDefinition

Options

This rule accepts a require object with its properties as

  • FunctionDeclaration (default: true)
  • ClassDeclaration (default: false)
  • MethodDefinition (default: false)

Default option settings are

{
    "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": false,
            "ClassDeclaration": false
        }
    }]
}

The following patterns are considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

function foo() {
    return 10;
}

class Test{
    getDate(){}
}

The following patterns are not considered problems:

/*eslint "require-jsdoc": ["error", {
    "require": {
        "FunctionDeclaration": true,
        "MethodDefinition": true,
        "ClassDeclaration": true
    }
}]*/

/**
* It returns 10
*/
function foo() {
    return 10;
}

/**
* It returns 10
*/
var foo = function() {
    return 10;
}

var array = [1,2,3];
array.filter(function(item) {
    return item > 2;
});

/**
* It returns 10
*/
class Test{
    /**
    * returns the date
    */
    getDate(){}
}

When Not To Use It

If you do not require JSDoc for your functions, then you can leave this rule off.

Related Rules

'iViz' is not defined.
Open

                  iViz.priorityManager
Severity: Minor
Found in app/scripts/model/dataProxy.js by eslint

Disallow Undeclared Variables (no-undef)

This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer).

Rule Details

Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment.

Examples of incorrect code for this rule:

/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

Examples of correct code for this rule with global declaration:

/*global someFunction b:true*/
/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

The b:true syntax in /*global */ indicates that assignment to b is correct.

Examples of incorrect code for this rule with global declaration:

/*global b*/
/*eslint no-undef: "error"*/

b = 10;

By default, variables declared in /*global */ are read-only, therefore assignment is incorrect.

Options

  • typeof set to true will warn for variables used inside typeof check (Default false).

typeof

Examples of correct code for the default { "typeof": false } option:

/*eslint no-undef: "error"*/

if (typeof UndefinedIdentifier === "undefined") {
    // do something ...
}

You can use this option if you want to prevent typeof check on a variable which has not been declared.

Examples of incorrect code for the { "typeof": true } option:

/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Examples of correct code for the { "typeof": true } option with global declaration:

/*global a*/
/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Environments

For convenience, ESLint provides shortcuts that pre-define global variables exposed by popular libraries and runtime environments. This rule supports these environments, as listed in Specifying Environments. A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

/*eslint no-undef: "error"*/
/*eslint-env browser*/

setTimeout(function() {
    alert("Hello");
});

node

Examples of correct code for this rule with node environment:

/*eslint no-undef: "error"*/
/*eslint-env node*/

var fs = require("fs");
module.exports = function() {
    console.log(fs);
};

When Not To Use It

If explicit declaration of global variables is not to your taste.

Compatibility

This rule provides compatibility with treatment of global variables in JSHint and JSLint.

Further Reading

Line 658 exceeds the maximum line length of 80.
Open

            url: window.cbioURL + 'api/clinical-data/fetch?clinicalDataType=PATIENT&projection=SUMMARY',
Severity: Minor
Found in app/scripts/model/dataProxy.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

Strings must use singlequote.
Open

              "identifiers": identifiers
Severity: Minor
Found in app/scripts/model/dataProxy.js by eslint

Enforce Quote Style (quotes)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

JavaScript allows you to define strings in one of three ways: double quotes, single quotes, and backticks (as of ECMAScript 6). For example:

/*eslint-env es6*/

var double = "double";
var single = 'single';
var backtick = `backtick`;    // ES6 only

Each of these lines creates a string and, in some cases, can be used interchangeably. The choice of how to define strings in a codebase is a stylistic one outside of template literals (which allow embedded of expressions to be interpreted).

Many codebases require strings to be defined in a consistent manner.

Rule Details

This rule is aimed at ensuring consistency of string quotes and as such will report a problem when an inconsistent style is found.

The rule configuration takes up to two options:

  1. The first option is "double", "single" or "backtick" for double-quotes, single-quotes or backticks respectively. The default is "double".
  2. The second option takes two options:
    1. "avoidEscape": When using "avoidEscape", this rule will not report a problem when a string is using single-quotes or double-quotes so long as the string contains a quote that would have to be escaped otherwise. For example, if you specify "double" and "avoidEscape", the string 'He said, "hi!"' is not considered a problem because using double quotes for that string would require escaping the double quotes inside of the string. This option is off by default.
    2. "allowTemplateLiterals": when using "allowTemplateLiterals", this rule will not report a problem when a string is using backticks and option one is either "double" or "single".

When using "single" or "double", template literals that don't contain a substitution, don't contain a line break and aren't tagged templates, are flagged as problems, even with the "avoidEscape" option. However they are not problems when "allowTemplateLiterals" is used.

Configuration looks like this:

[2, "single", {"avoidEscape": true, "allowTemplateLiterals": true}]

Deprecation notice: The avoid-escape option is a deprecated syntax and you should use the object form instead.

The following patterns are considered problems:

/*eslint quotes: ["error", "double"]*/

var single = 'single';
var unescaped = 'a string containing "double" quotes';
/*eslint quotes: ["error", "single"]*/

var double = "double";
var unescaped = "a string containing 'single' quotes";
/*eslint quotes: ["error", "double", {"avoidEscape": true}]*/

var single = 'single';
var single = `single`;
/*eslint quotes: ["error", "single", {"avoidEscape": true}]*/

var double = "double";
var double = `double`;
/*eslint quotes: ["error", "backtick"]*/

var single = 'single';
var double = "double";
var unescaped = 'a string containing `backticks`';
/*eslint quotes: ["error", "backtick", {"avoidEscape": true}]*/

var single = 'single';
var double = "double";

The following patterns are not considered problems:

/*eslint quotes: ["error", "double"]*/
/*eslint-env es6*/

var double = "double";
var backtick = `back\ntick`;  // backticks are allowed due to newline
var backtick = tag`backtick`; // backticks are allowed due to tag
/*eslint quotes: ["error", "single"]*/
/*eslint-env es6*/

var single = 'single';
var backtick = `back${x}tick`; // backticks are allowed due to substitution
/*eslint quotes: ["error", "double", {"avoidEscape": true}]*/

var single = 'a string containing "double" quotes';
/*eslint quotes: ["error", "single", {"avoidEscape": true}]*/

var double = "a string containing 'single' quotes";
/*eslint quotes: ["error", "double", {"allowTemplateLiterals": true}]*/

var single = 'single';
var single = `single`;
/*eslint quotes: ["error", "single", {"allowTemplateLiterals": true}]*/

var double = "double";
var double = `double`;
/*eslint quotes: ["error", "backtick"]*/
/*eslint-env es6*/

var backtick = `backtick`;
/*eslint quotes: ["error", "backtick", {"avoidEscape": true}]*/

var double = "a string containing `backtick` quotes"

When Not To Use It

If you do not need consistency in your string styles, you can safely disable this rule. Source: http://eslint.org/docs/rules/

Inconsistently quoted property 'transform' found.
Open

            style: {

Quoting Style for Property Names (quote-props)

Object literal property names can be defined in two ways: using literals or using strings. For example, these two objects are equivalent:

var object1 = {
    property: true
};

var object2 = {
    "property": true
};

In many cases, it doesn't matter if you choose to use an identifier instead of a string or vice-versa. Even so, you might decide to enforce a consistent style in your code.

There are, however, some occasions when you must use quotes:

  1. If you are using an ECMAScript 3 JavaScript engine (such as IE8) and you want to use a keyword (such as if) as a property name. This restriction was removed in ECMAScript 5.
  2. You want to use a non-identifier character in your property name, such as having a property with a space like "one two".

Another example where quotes do matter is when using numeric literals as property keys:

var object = {
    1e2: 1,
    100: 2
};

This may look alright at first sight, but this code in fact throws a syntax error in ECMAScript 5 strict mode. This happens because 1e2 and 100 are coerced into strings before getting used as the property name. Both String(1e2) and String(100) happen to be equal to "100", which causes the "Duplicate data property in object literal not allowed in strict mode" error. Issues like that can be tricky to debug, so some prefer to require quotes around all property names.

Rule Details

This rule aims to enforce use of quotes in property names and as such will flag any properties that don't use quotes (default behavior).

Options

There are four behaviors for this rule: "always" (default), "as-needed", "consistent" and "consistent-as-needed". You can define these options in your configuration as:

{
    "quote-props": ["error", "as-needed"]
}

"always"

When configured with "always" as the first option (the default), quoting for all properties will be enforced. Some believe that ensuring property names in object literals are always wrapped in quotes is generally a good idea, since depending on the property name you may need to quote them anyway. Consider this example:

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

Here, the properties foo and baz are not wrapped in quotes, but qux-lorem is, because it doesn’t work without the quotes. This is rather inconsistent. Instead, you may prefer to quote names of all properties:

var object = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

or, if you prefer single quotes:

var object = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

When configured with "always" as the first option (the default), quoting for all properties will be enforced. The following patterns are considered problems:

/*eslint quote-props: ["error", "always"]*/

var object = {
    foo: "bar",
    baz: 42,
    "qux-lorem": true
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "always"]*/
/*eslint-env es6*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

"as-needed"

When configured with "as-needed" as the first option, quotes will be enforced when they are strictly required, and unnecessary quotes will cause warnings. The following patterns are considered problems:

/*eslint quote-props: ["error", "as-needed"]*/

var object = {
    "a": 0,
    "0": 0,
    "true": 0,
    "null": 0
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "as-needed"]*/
/*eslint-env es6*/

var object1 = {
    "a-b": 0,
    "0x0": 0,
    "1e2": 0
};

var object2 = {
    foo: 'bar',
    baz: 42,
    true: 0,
    0: 0,
    'qux-lorem': true
};

var object3 = {
    foo() {
        return;
    }
};

When the "as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords should be quoted as properties. By default it is set to false.

{
    "quote-props": ["error", "as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

Another modifier for this rule is the unnecessary option which defaults to true. Setting this to false will prevent the rule from complaining about unnecessarily quoted properties. This comes in handy when you only care about quoting keywords.

{
    "quote-props": ["error", "as-needed", { "keywords": true, "unnecessary": false }]
}

When unnecessary is set to false, the following patterns stop being problems:

/*eslint quote-props: ["error", "as-needed", { "keywords": true, "unnecessary": false }]*/

var x = {
    "while": 1,
    "foo": "bar"  // Would normally have caused a warning
};

A numbers flag, with default value false, can also be used as a modifier for the "as-needed" mode. When it is set to true, numeric literals should always be quoted.

{
    "quote-props": ["error", "as-needed", {"numbers": true}]
}

When numbers is set to true, the following patterns become problems:

/*eslint quote-props: ["error", "as-needed", { "numbers": true }]*/

var x = {
    100: 1
}

and the following patterns stop being problems:

var x = {
    "100": 1
}

"consistent"

When configured with "consistent", the patterns below are considered problems. Basically "consistent" means all or no properties are expected to be quoted, in other words quoting style can't be mixed within an object. Please note the latter situation (no quotation at all) isn't always possible as some property names require quoting.

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    baz: 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

var object3 = {
    foo: 'bar',
    baz: 42
};

"consistent-as-needed"

When configured with "consistent-as-needed", the behavior is similar to "consistent" with one difference. Namely, properties' quoting should be consistent (as in "consistent") but whenever all quotes are redundant a warning is raised. In other words if at least one property name has to be quoted (like qux-lorem) then all property names must be quoted, otherwise no properties can be quoted. The following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    foo: "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    'foo': 'bar',
    'baz': 42
};

The following patterns are not considered problems:

/*eslint quote-props: ["error", "consistent-as-needed"]*/

var object1 = {
    "foo": "bar",
    "baz": 42,
    "qux-lorem": true
};

var object2 = {
    foo: 'bar',
    baz: 42
};

When the "consistent-as-needed" mode is selected, an additional keywords option can be provided. This flag indicates whether language keywords can be used unquoted as properties. By default it is set to false.

{
    "quote-props": ["error", "consistent-as-needed", { "keywords": true }]
}

When keywords is set to true, the following patterns are considered problems:

/*eslint quote-props: ["error", "consistent-as-needed", { "keywords": true }]*/

var x = {
    while: 1,
    volatile: "foo"
};

When Not To Use It

If you don't care if property names are consistently wrapped in quotes or not, and you don't target legacy ES3 environments, turn this rule off.

Further Reading

Expected a conditional expression and instead saw an assignment.
Open

        } else if (self.type = 'infinite') {

disallow assignment operators in conditional statements (no-cond-assign)

In conditional statements, it is very easy to mistype a comparison operator (such as ==) as an assignment operator (such as =). For example:

// Check the user's job title
if (user.jobTitle = "manager") {
    // user.jobTitle is now incorrect
}

There are valid reasons to use assignment operators in conditional statements. However, it can be difficult to tell whether a specific assignment was intentional.

Rule Details

This rule disallows ambiguous assignment operators in test conditions of if, for, while, and do...while statements.

Options

This rule has a string option:

  • "except-parens" (default) allows assignments in test conditions only if they are enclosed in parentheses (for example, to allow reassigning a variable in the test of a while or do...while loop)
  • "always" disallows all assignments in test conditions

except-parens

Examples of incorrect code for this rule with the default "except-parens" option:

/*eslint no-cond-assign: "error"*/

// Unintentional assignment
var x;
if (x = 0) {
    var b = 1;
}

// Practical example that is similar to an error
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while (someNode = someNode.parentNode);
}

Examples of correct code for this rule with the default "except-parens" option:

/*eslint no-cond-assign: "error"*/

// Assignment replaced by comparison
var x;
if (x === 0) {
    var b = 1;
}

// Practical example that wraps the assignment in parentheses
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode));
}

// Practical example that wraps the assignment and tests for 'null'
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode) !== null);
}

always

Examples of incorrect code for this rule with the "always" option:

/*eslint no-cond-assign: ["error", "always"]*/

// Unintentional assignment
var x;
if (x = 0) {
    var b = 1;
}

// Practical example that is similar to an error
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while (someNode = someNode.parentNode);
}

// Practical example that wraps the assignment in parentheses
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode));
}

// Practical example that wraps the assignment and tests for 'null'
function setHeight(someNode) {
    "use strict";
    do {
        someNode.height = "100px";
    } while ((someNode = someNode.parentNode) !== null);
}

Examples of correct code for this rule with the "always" option:

/*eslint no-cond-assign: ["error", "always"]*/

// Assignment replaced by comparison
var x;
if (x === 0) {
    var b = 1;
}

Further Reading

Related Rules

Line 926 exceeds the maximum line length of 80.
Open

                if (_.isArray(self.data.sampleLists[studyId][studyId + '_sequenced'])) {
Severity: Minor
Found in app/scripts/model/dataProxy.js by eslint

enforce a maximum line length (max-len)

Very long lines of code in any language can be difficult to read. In order to aid in readability and maintainability many coders have developed a convention to limit lines of code to X number of characters (traditionally 80 characters).

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" }; // very long

Rule Details

This rule enforces a maximum line length to increase code readability and maintainability.

Note: This rule calculates the length of a line via code points, not characters. That means if you use a double-byte character in your code, it will count as 2 code points instead of 1, and 2 will be used to calculate line length. This is a technical limitation of JavaScript that is made easier with ES2015, and we will look to update this when ES2015 is available in Node.js.

Options

This rule has a number or object option:

  • "code" (default 80) enforces a maximum line length
  • "tabWidth" (default 4) specifies the character width for tab characters
  • "comments" enforces a maximum line length for comments; defaults to value of code
  • "ignorePattern" ignores lines matching a regular expression; can only match a single line and need to be double escaped when written in YAML or JSON
  • "ignoreComments": true ignores all trailing comments and comments on their own line
  • "ignoreTrailingComments": true ignores only trailing comments
  • "ignoreUrls": true ignores lines that contain a URL

code

Examples of incorrect code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" }, "difficult": "to read" };

Examples of correct code for this rule with the default { "code": 80 } option:

/*eslint max-len: ["error", 80]*/

var foo = {
  "bar": "This is a bar.",
  "baz": { "qux": "This is a qux" },
  "easier": "to read"
};

tabWidth

Examples of incorrect code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = { "bar": "This is a bar.", "baz": { "qux": "This is a qux" } };

Examples of correct code for this rule with the default { "tabWidth": 4 } option:

/*eslint max-len: ["error", 80, 4]*/

\t  \t  var foo = {
\t  \t  \t  \t  "bar": "This is a bar.",
\t  \t  \t  \t  "baz": { "qux": "This is a qux" }
\t  \t  };

comments

Examples of incorrect code for this rule with the { "comments": 65 } option:

/*eslint max-len: ["error", { "comments": 65 }]*/

/**
 * This is a comment that violates the maximum line length we have specified
**/

ignoreComments

Examples of correct code for this rule with the { "ignoreComments": true } option:

/*eslint max-len: ["error", { "ignoreComments": true }]*/

/**
 * This is a really really really really really really really really really long comment
**/

ignoreTrailingComments

Examples of correct code for this rule with the { "ignoreTrailingComments": true } option:

/*eslint max-len: ["error", { "ignoreTrailingComments": true }]*/

var foo = 'bar'; // This is a really really really really really really really long comment

ignoreUrls

Examples of correct code for this rule with the { "ignoreUrls": true } option:

/*eslint max-len: ["error", { "ignoreUrls": true }]*/

var url = 'https://www.example.com/really/really/really/really/really/really/really/long';

ignorePattern

Examples of correct code for this rule with the { "ignorePattern": true } option:

/*eslint max-len: ["error", { "ignorePattern": "^\\s*var\\s.+=\\s*require\\s*\\(/" }]*/

var dep = require('really/really/really/really/really/really/really/really/long/module');

Related Rules

  • [complexity](complexity.md)
  • [max-depth](max-depth.md)
  • [max-nested-callbacks](max-nested-callbacks.md)
  • [max-params](max-params.md)
  • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/
Severity
Category
Status
Source
Language