Line 1 exceeds the maximum line length of 100. Open
/*global Switchery:true*/ // Meteor creates a file-scope global for exporting. This comment prevents a potential JSHint warning.
- 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. The length of a line is defined as the number of Unicode characters in the line.
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 -
"ignoreStrings": true
ignores lines that contain a double-quoted or single-quoted string -
"ignoreTemplateLiterals": true
ignores lines that contain a template literal -
"ignoreRegExpLiterals": true
ignores lines that contain a RegExp literal
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';
ignoreStrings
Examples of correct code for this rule with the { "ignoreStrings": true }
option:
/*eslint max-len: ["error", { "ignoreStrings": true }]*/
var longString = 'this is a really really really really really long string!';
ignoreTemplateLiterals
Examples of correct code for this rule with the { "ignoreTemplateLiterals": true }
option:
/*eslint max-len: ["error", { "ignoreTemplateLiterals": true }]*/
var longTemplateLiteral = `this is a really really really really really long template literal!`;
ignoreRegExpLiterals
Examples of correct code for this rule with the { "ignoreRegExpLiterals": true }
option:
/*eslint max-len: ["error", { "ignoreRegExpLiterals": true }]*/
var longRegExpLiteral = /this is a really really really really really long regular expression!/;
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/
'window' is not defined. Open
Switchery = window.Switchery;
- Read upRead up
- Exclude checks
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. Source: http://eslint.org/docs/rules/
'window' is not defined. Open
delete window.Switchery;
- Read upRead up
- Exclude checks
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. Source: http://eslint.org/docs/rules/
Expected exception block, space or tab after '/*' in comment. Open
/*global Switchery:true*/ // Meteor creates a file-scope global for exporting. This comment prevents a potential JSHint warning.
- Read upRead up
- Exclude checks
Requires or disallows a whitespace (space or tab) beginning a comment (spaced-comment)
Some style guides require or disallow a whitespace immediately after the initial //
or /*
of a comment.
Whitespace after the //
or /*
makes it easier to read text in comments.
On the other hand, commenting out code is easier without having to put a whitespace right after the //
or /*
.
Rule Details
This rule will enforce consistency of spacing after the start of a comment //
or /*
. It also provides several
exceptions for various documentation styles.
Options
The rule takes two options.
-
The first is a string which be either
"always"
or"never"
. The default is"always"
.- If
"always"
then the//
or/*
must be followed by at least one whitespace. - If
"never"
then there should be no whitespace following.
- If
-
This rule can also take a 2nd option, an object with any of the following keys:
"exceptions"
and"markers"
.- The
"exceptions"
value is an array of string patterns which are considered exceptions to the rule. Please note that exceptions are ignored if the first argument is"never"
.
"spaced-comment": ["error", "always", { "exceptions": ["-", "+"] }]
- The
"markers"
value is an array of string patterns which are considered markers for docblock-style comments, such as an additional/
, used to denote documentation read by doxygen, vsdoc, etc. which must have additional characters. The"markers"
array will apply regardless of the value of the first argument, e.g."always"
or"never"
.
"spaced-comment": ["error", "always", { "markers": ["/"] }]
- The
The difference between a marker and an exception is that a marker only appears at the beginning of the comment whereas exceptions can occur anywhere in the comment string.
You can also define separate exceptions and markers for block and line comments. The "block"
object can have an additional key "balanced"
, a boolean that specifies if inline block comments should have balanced spacing. The default value is false
.
If
"balanced": true
and"always"
then the/*
must be followed by at least one whitespace, and the*/
must be preceded by at least one whitespace.If
"balanced": true
and"never"
then there should be no whitespace following/*
or preceding*/
.If
"balanced": false
then balanced whitespace is not enforced.
"spaced-comment": ["error", "always", {
"line": {
"markers": ["/"],
"exceptions": ["-", "+"]
},
"block": {
"markers": ["!"],
"exceptions": ["*"],
"balanced": true
}
}]
always
Examples of incorrect code for this rule with the "always"
option:
/*eslint spaced-comment: ["error", "always"]*/
//This is a comment with no whitespace at the beginning
/*This is a comment with no whitespace at the beginning */
/* eslint spaced-comment: ["error", "always", { "block": { "balanced": true } }] */
/* This is a comment with whitespace at the beginning but not the end*/
Examples of correct code for this rule with the "always"
option:
/* eslint spaced-comment: ["error", "always"] */
// This is a comment with a whitespace at the beginning
/* This is a comment with a whitespace at the beginning */
/*
* This is a comment with a whitespace at the beginning
*/
/*
This comment has a newline
*/
/* eslint spaced-comment: ["error", "always"] */
/**
* I am jsdoc
*/
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint spaced-comment: ["error", "never"]*/
// This is a comment with a whitespace at the beginning
/* This is a comment with a whitespace at the beginning */
/* \nThis is a comment with a whitespace at the beginning */
/*eslint spaced-comment: ["error", "never", { "block": { "balanced": true } }]*/
/*This is a comment with whitespace at the end */
Examples of correct code for this rule with the "never"
option:
/*eslint spaced-comment: ["error", "never"]*/
/*This is a comment with no whitespace at the beginning */
/*eslint spaced-comment: ["error", "never"]*/
/**
* I am jsdoc
*/
exceptions
Examples of incorrect code for this rule with the "always"
option combined with "exceptions"
:
/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-"] } }] */
//--------------
// Comment block
//--------------
/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */
//------++++++++
// Comment block
//------++++++++
/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */
/*------++++++++*/
/* Comment block */
/*------++++++++*/
/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-+"] } }] */
/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/
Examples of correct code for this rule with the "always"
option combined with "exceptions"
:
/* eslint spaced-comment: ["error", "always", { "exceptions": ["-"] }] */
//--------------
// Comment block
//--------------
/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-"] } }] */
//--------------
// Comment block
//--------------
/* eslint spaced-comment: ["error", "always", { "exceptions": ["*"] }] */
/****************
* Comment block
****************/
/* eslint spaced-comment: ["error", "always", { "exceptions": ["-+"] }] */
//-+-+-+-+-+-+-+
// Comment block
//-+-+-+-+-+-+-+
/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/
/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-+"] } }] */
/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/
markers
Examples of incorrect code for this rule with the "always"
option combined with "markers"
:
/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */
///This is a comment with a marker but without whitespace
/*eslint spaced-comment: ["error", "always", { "block": { "markers": ["!"], "balanced": true } }]*/
/*! This is a comment with a marker but without whitespace at the end*/
/*eslint spaced-comment: ["error", "never", { "block": { "markers": ["!"], "balanced": true } }]*/
/*!This is a comment with a marker but with whitespace at the end */
Examples of correct code for this rule with the "always"
option combined with "markers"
:
/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */
/// This is a comment with a marker
/*eslint spaced-comment: ["error", "never", { "markers": ["!<"] }]*/
//!<this is a line comment with marker block subsequent lines are ignored></this>
/* eslint spaced-comment: ["error", "always", { "markers": ["global"] }] */
/*global ABC*/
Related Rules
- [spaced-line-comment](spaced-line-comment.md) Source: http://eslint.org/docs/rules/
Newline required at end of file but not found. Open
delete window.Switchery;
- Read upRead up
- Exclude checks
require or disallow newline at the end of files (eol-last)
Trailing newlines in non-empty files are a common UNIX idiom. Benefits of trailing newlines include the ability to concatenate or append to files as well as output files to the terminal without interfering with shell prompts.
Rule Details
This rule enforces at least one newline (or absence thereof) at the end of non-empty files.
Prior to v0.16.0 this rule also enforced that there was only a single line at
the end of the file. If you still want this behaviour, consider enabling
[no-multiple-empty-lines](no-multiple-empty-lines.md) with maxEOF
and/or
[no-trailing-spaces](no-trailing-spaces.md).
Examples of incorrect code for this rule:
/*eslint eol-last: ["error", "always"]*/
function doSmth() {
var foo = 2;
}
Examples of correct code for this rule:
/*eslint eol-last: ["error", "always"]*/
function doSmth() {
var foo = 2;
}\n
Options
This rule has a string option:
-
"always"
(default) enforces that files end with a newline (LF) -
"never"
enforces that files do not end with a newline -
"unix"
(deprecated) is identical to "always" -
"windows"
(deprecated) is identical to "always", but will use a CRLF character when autofixing
Deprecated: The options "unix"
and "windows"
are deprecated. If you need to enforce a specific linebreak style, use this rule in conjunction with linebreak-style
.
Source: http://eslint.org/docs/rules/