Function TableView
has 408 lines of code (exceeds 25 allowed). Consider refactoring. Open
iViz.view.component.TableView = function() {
var content = this;
var chartId_;
var data_ = [];
var type_ = '';
File tableView.js
has 579 lines of code (exceeds 250 allowed). Consider refactoring. Open
/**
* Created by Karthik Kalletla on 6/20/16.
*/
'use strict';
(function(iViz, dc, _, React, ReactDOM, EnhancedFixedDataTableSpecial) {
Function tableView
has 155 lines of code (exceeds 25 allowed). Consider refactoring. Open
iViz.util.tableView = (function() {
var content = {};
content.compare = function(arr1, arr2) {
if (arr1.length !== arr2.length) {
return false;
Function getAttributes
has 140 lines of code (exceeds 25 allowed). Consider refactoring. Open
content.getAttributes = function(type) {
var _attr = [];
switch (type) {
case 'mutatedGene':
_attr = [
Function mutatedGenesData
has 71 lines of code (exceeds 25 allowed). Consider refactoring. Open
function mutatedGenesData(_selectedGenesMap, _selectedSampleUids) {
genePanelMap = window.iviz.datamanager.updateGenePanelMap(genePanelMap, _selectedSampleUids);
selectedGeneData.length = 0;
var numOfCases_ = content.getCases().length;
Function update
has 66 lines of code (exceeds 25 allowed). Consider refactoring. Open
content.update = function(_selectedSampleUIDs, _selectedRows) {
var selectedMap_ = {};
var includeMutationCount = false;
if (_selectedRows !== undefined) {
selectedRows = _selectedRows;
Function initReactTable
has 47 lines of code (exceeds 25 allowed). Consider refactoring. Open
function initReactTable(_reloadData, _selectedSampleUids, _selectedMap) {
if (_reloadData) {
reactTableData = initReactData(_selectedMap, _selectedSampleUids);
}
var _opts = {
Function initTsvDownloadData
has 35 lines of code (exceeds 25 allowed). Consider refactoring. Open
function initTsvDownloadData() {
var attrs =
iViz.util.tableView.getAttributes(type_).filter(function(attr) {
return attr.attr_id !== 'uniqueId' && (_.isBoolean(attr.show) ? attr.show : true);
});
Function init
has 9 arguments (exceeds 4 allowed). Consider refactoring. Open
function(_attributes, _opts, _selectedSamples, _selectedGenes,
_data, _callbacks, _geneData, _dimension, _genePanelMap) {
Function initReactData
has 27 lines of code (exceeds 25 allowed). Consider refactoring. Open
function initReactData(_selectedMap, _selectedSampleUids) {
attr_ = iViz.util.tableView.getAttributes(type_);
var result = {
data: [],
attributes: attr_
Avoid deeply nested control flow statements. Open
if (!selectedMap_.hasOwnProperty(category)) {
selectedMap_[category] = [];
}
Avoid deeply nested control flow statements. Open
if (!category) {
category = 'NA';
}
Avoid deeply nested control flow statements. Open
if (selectedMap_[geneIndex] === undefined) {
selectedMap_[geneIndex] = {};
if (includeMutationCount) {
selectedMap_[geneIndex].num_muts = 1;
}
Identical blocks of code found in 2 locations. Consider refactoring. Open
if (typeof genePanelMap[item.gene] !== 'undefined') {
freq = iViz.util.calcFreq(datum.cases, genePanelMap[item.gene].sampleNum);
} else {
freq = iViz.util.calcFreq(datum.cases, numOfCases_);
}
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 85.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Identical blocks of code found in 2 locations. Consider refactoring. Open
if (typeof genePanelMap[item.gene] !== 'undefined') {
freq = iViz.util.calcFreq(datum.cases, genePanelMap[item.gene].sampleNum);
} else {
freq = iViz.util.calcFreq(datum.cases, numOfCases_);
}
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 85.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Similar blocks of code found in 4 locations. Consider refactoring. Open
_.each(selectedMap_, function(content) {
content.case_uids = iViz.util.unique(content.case_ids);
});
- Read upRead up
Duplicated Code
Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).
Tuning
This issue has a mass of 45.
We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.
The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.
If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.
See codeclimate-duplication
's documentation for more information about tuning the mass threshold in your .codeclimate.yml
.
Refactorings
- Extract Method
- Extract Class
- Form Template Method
- Introduce Null Object
- Pull Up Method
- Pull Up Field
- Substitute Algorithm
Further Reading
- Don't Repeat Yourself on the C2 Wiki
- Duplicated Code on SourceMaking
- Refactoring: Improving the Design of Existing Code by Martin Fowler. Duplicated Code, p76
Missing JSDoc comment. Open
function initRegularTableData() {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Line 418 exceeds the maximum line length of 80. Open
return attr.attr_id !== 'uniqueId' && (_.isBoolean(attr.show) ? attr.show : true);
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
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/
Missing JSDoc comment. Open
function initReactTable(_reloadData, _selectedSampleUids, _selectedMap) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
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 381 exceeds the maximum line length of 80. Open
attr_val: key === 'case_uids' ? item.case_uids.join(',') : item[key]
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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/
Unexpected negated condition. Open
if (typeof genePanelMap[item.gene] !== 'undefined') {
- Read upRead up
- Exclude checks
Disallow use of negated expressions in conditions (no-negated-condition)
Checks against the use of a negated expression in an if condition when the else branch is not empty or in a ternary operator. Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition instead.
For example:
if (!a) {
doSomething();
}
else {
doSomethingElse();
}
should instead be written as:
if (a) {
doSomethingElse();
}
else {
doSomething();
}
Rule Details
The rule is aimed at preventing the use of a negated expression in a condition.
The following patterns are considered warnings:
/*eslint no-negated-condition: "error"*/
if (!a) {
doSomething();
} else {
doSomethingElse();
}
if (a != b) {
doSomething();
} else {
doSomethingElse();
}
if (a !== b) {
doSomething();
} else {
doSomethingElse();
}
!a ? b : c
The following patterns are not warnings:
/*eslint no-negated-condition: "error"*/
if (!a) {
doSomething();
}
if (!a) {
doSomething();
} else if (b) {
doSomething();
}
if (a != b) {
doSomething();
}
a ? b : c
Source: http://eslint.org/docs/rules/
Missing JSDoc comment. Open
function reactRowClickCallback(data, selected) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Line 223 exceeds the maximum line length of 80. Open
renderedReactTable = ReactDOM.render(testElement, document.getElementById(chartId_));
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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 234 exceeds the maximum line length of 80. Open
attr_val: key === 'case_uids' ? category.case_uids.join(',') : category[key]
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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/
Block must not be padded by blank lines. Open
}
- Read upRead up
- Exclude checks
Enforce padding within blocks (padded-blocks)
Some style guides require block statements to start and end with blank lines. The goal is to improve readability by visually separating the block content and the surrounding code.
if (a) {
b();
}
Since it's good to have a consistent code style, you should either always write padded blocks or never do it.
Rule Details
This rule enforces consistent padding within blocks.
This rule takes one argument, which can be an string or an object. If it is "always"
(the default) then block statements must start and end with a blank line. If "never"
, then block statements should neither start nor end with a blank line. By default, this rule ignores padding in switch statements and classes.
If you want to enforce padding within switches and classes, a configuration object can be passed as the rule argument to configure the cases separately ( e.g. { "blocks": "always", "switches": "always", "classes": "always" }
).
The following patterns are considered problems when set to "always"
:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
The following patterns are not considered problems when set to "always"
:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
The following patterns are considered problems when set to "never"
:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
The following patterns are not considered problems when set to "never"
:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
The following patterns are considered problems when configured { "switches": "always" }
:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
The following patterns are not considered problems when configured { "switches": "always" }
:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
The following patterns are considered problems when configured { "switches": "never" }
:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
The following patterns are not considered problems when configured { "switches": "never" }
:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
The following patterns are considered problems when configured { "classes": "always" }
:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
The following patterns are not considered problems when configured { "classes": "always" }
:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
The following patterns are considered problems when configured { "classes": "never" }
:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
The following patterns are not considered problems when configured { "classes": "never" }
:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of padding within blocks. Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
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 305 exceeds the maximum line length of 80. Open
freq = iViz.util.calcFreq(datum.cases, genePanelMap[item.gene].sampleNum);
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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 initTsvDownloadData() {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Line 284 exceeds the maximum line length of 80. Open
label.caseRate = iViz.util.calcFreq(Number(label.cases), _currentSampleSize);
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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 329 exceeds the maximum line length of 80. Open
freq = iViz.util.calcFreq(datum.cases, genePanelMap[item.gene].sampleNum);
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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 getColor(key) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Line 290 exceeds the maximum line length of 80. Open
genePanelMap = window.iviz.datamanager.updateGenePanelMap(genePanelMap, _selectedSampleUids);
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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(_selectedMap, _selectedSampleUids) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
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/
Missing JSDoc comment. Open
function mutatedGenesData(_selectedGenesMap, _selectedSampleUids) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Unexpected negated condition. Open
if (typeof genePanelMap[item.gene] !== 'undefined') {
- Read upRead up
- Exclude checks
Disallow use of negated expressions in conditions (no-negated-condition)
Checks against the use of a negated expression in an if condition when the else branch is not empty or in a ternary operator. Negated conditions are more difficult to understand. Code can be made more readable by inverting the condition instead.
For example:
if (!a) {
doSomething();
}
else {
doSomethingElse();
}
should instead be written as:
if (a) {
doSomethingElse();
}
else {
doSomething();
}
Rule Details
The rule is aimed at preventing the use of a negated expression in a condition.
The following patterns are considered warnings:
/*eslint no-negated-condition: "error"*/
if (!a) {
doSomething();
} else {
doSomethingElse();
}
if (a != b) {
doSomething();
} else {
doSomethingElse();
}
if (a !== b) {
doSomething();
} else {
doSomethingElse();
}
!a ? b : c
The following patterns are not warnings:
/*eslint no-negated-condition: "error"*/
if (!a) {
doSomething();
}
if (!a) {
doSomething();
} else if (b) {
doSomething();
}
if (a != b) {
doSomething();
}
a ? b : c
Source: http://eslint.org/docs/rules/
Missing JSDoc comment. Open
function reactSubmitClickCallback() {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Trailing spaces not allowed. Open
- Read upRead up
- Exclude checks
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/
Missing JSDoc comment. Open
function initPieTableData() {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Missing JSDoc comment. Open
function updateCategories() {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/
Line 61 exceeds the maximum line length of 80. Open
sequencedSampleIds = _attributes.options.sequencedCases === undefined ? allSamplesIds : _attributes.options.sequencedCases;
- Read upRead up
- Exclude checks
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"
(default80
) enforces a maximum line length -
"tabWidth"
(default4
) specifies the character width for tab characters -
"comments"
enforces a maximum line length for comments; defaults to value ofcode
-
"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 reactGeneClickCallback(selectedRow) {
- Read upRead up
- Exclude checks
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
- [valid-jsdoc](valid-jsdoc.md) Source: http://eslint.org/docs/rules/