Block must not be padded by blank lines. Open
vcSession.model = (function() {
- 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/
Line 12 exceeds the maximum line length of 80. Open
var url = window.cbioURL+'api-legacy/proxy/session/virtual_study'+ (addToUserStudies ? '/save' : '');
- 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/
Infix operators must be spaced. Open
var url = window.cbioURL+'api-legacy/proxy/session/virtual_study'+ (addToUserStudies ? '/save' : '');
- Read upRead up
- Exclude checks
Require Spaces Around Infix Operators (space-infix-ops)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
While formatting preferences are very personal, a number of style guides require spaces around operators, such as:
var sum = 1 + 2;
The proponents of these extra spaces believe it make the code easier to read and can more easily highlight potential errors, such as:
var sum = i+++2;
While this is valid JavaScript syntax, it is hard to determine what the author intended.
Rule Details
This rule is aimed at ensuring there are spaces around infix operators.
Options
This rule accepts a single options argument with the following defaults:
"space-infix-ops": ["error", {"int32Hint": false}]
int32Hint
Set the int32Hint
option to true
(default is false
) to allow write a|0
without space.
var foo = bar|0; // `foo` is forced to be signed 32 bit integer
The following patterns are considered problems:
/*eslint space-infix-ops: "error"*/
/*eslint-env es6*/
a+b
a+ b
a +b
a?b:c
const a={b:1};
var {a=0}=bar;
function foo(a=0) { }
The following patterns are not considered problems:
/*eslint space-infix-ops: "error"*/
/*eslint-env es6*/
a + b
a + b
a ? b : c
const a = {b:1};
var {a = 0} = bar;
function foo(a = 0) { }
Source: http://eslint.org/docs/rules/
Infix operators must be spaced. Open
var url = window.cbioURL+'api-legacy/proxy/session/virtual_study'+ (addToUserStudies ? '/save' : '');
- Read upRead up
- Exclude checks
Require Spaces Around Infix Operators (space-infix-ops)
(fixable) The --fix
option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.
While formatting preferences are very personal, a number of style guides require spaces around operators, such as:
var sum = 1 + 2;
The proponents of these extra spaces believe it make the code easier to read and can more easily highlight potential errors, such as:
var sum = i+++2;
While this is valid JavaScript syntax, it is hard to determine what the author intended.
Rule Details
This rule is aimed at ensuring there are spaces around infix operators.
Options
This rule accepts a single options argument with the following defaults:
"space-infix-ops": ["error", {"int32Hint": false}]
int32Hint
Set the int32Hint
option to true
(default is false
) to allow write a|0
without space.
var foo = bar|0; // `foo` is forced to be signed 32 bit integer
The following patterns are considered problems:
/*eslint space-infix-ops: "error"*/
/*eslint-env es6*/
a+b
a+ b
a +b
a?b:c
const a={b:1};
var {a=0}=bar;
function foo(a=0) { }
The following patterns are not considered problems:
/*eslint space-infix-ops: "error"*/
/*eslint-env es6*/
a + b
a + b
a ? b : c
const a = {b:1};
var {a = 0} = bar;
function foo(a = 0) { }
Source: http://eslint.org/docs/rules/