Showing 74 of 74 total issues
Similar blocks of code found in 2 locations. Consider refactoring. Open
it('must not allow access to /add-applicant if auth == false', (done) => {
const server = mock(app, crippyOptions, errorAuth);
request(server).
post('/add-applicant').
send(formData).
- 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 95.
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 2 locations. Consider refactoring. Open
it('must allow access to /add-applicant if auth == true', (done) => {
const server = mock(app, goodOptions, verify);
request(server).
post('/add-applicant').
send(formData).
- 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 95.
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
Function default
has 37 lines of code (exceeds 25 allowed). Consider refactoring. Open
export default function (sequelize, DataTypes) {
const User = sequelize.define('user', {
// see http://docs.sequelizejs.com/en/latest/docs/models-definition/
type: {
type: DataTypes.ENUM,
Similar blocks of code found in 2 locations. Consider refactoring. Open
function registerRoutes(app:any) {
app.get('/about', 'about', (req, res) => {
res.send('About Interview');
});
}
- 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 46.
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 2 locations. Consider refactoring. Open
function registerRoutes(app:any) {
app.get('/', 'home', (req, res) => {
res.render('index');
});
}
- 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 46.
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 2 locations. Consider refactoring. Open
} else if (reqType === 'add-interviewer') {
debugServer('POST /add-interviewer', data);
const res = await sequelize.models.user.createInterviewer(data);
debugServer('Result', res);
}
- 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
Similar blocks of code found in 2 locations. Consider refactoring. Open
if (reqType === 'add-applicant') {
debugServer('POST /add-applicant', data);
const res = await sequelize.models.user.createApplicant(data);
debugServer('Result', res);
} else if (reqType === 'add-interviewer') {
- 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
Expected empty line after import statement not followed by another import. Open
import debug from 'debug';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Missing trailing comma. Open
res.send(ops)
- Read upRead up
- Exclude checks
require or disallow trailing commas (comma-dangle)
Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript.
var foo = {
bar: "baz",
qux: "quux",
};
Trailing commas simplify adding and removing items to objects and arrays, since only the lines you are modifying must be touched. Another argument in favor of trailing commas is that it improves the clarity of diffs when an item is added or removed from an object or array:
Less clear:
var foo = {
- bar: "baz",
- qux: "quux"
+ bar: "baz"
};
More clear:
var foo = {
bar: "baz",
- qux: "quux",
};
Rule Details
This rule enforces consistent use of trailing commas in object and array literals.
Options
This rule has a string option or an object option:
{
"comma-dangle": ["error", "never"],
// or
"comma-dangle": ["error", {
"arrays": "never",
"objects": "never",
"imports": "never",
"exports": "never",
"functions": "ignore",
}]
}
-
"never"
(default) disallows trailing commas -
"always"
requires trailing commas -
"always-multiline"
requires trailing commas when the last element or property is in a different line than the closing]
or}
and disallows trailing commas when the last element or property is on the same line as the closing]
or}
-
"only-multiline"
allows (but does not require) trailing commas when the last element or property is in a different line than the closing]
or}
and disallows trailing commas when the last element or property is on the same line as the closing]
or}
Trailing commas in function declarations and function calls are valid syntax since ECMAScript 2017; however, the string option does not check these situations for backwards compatibility.
You can also use an object option to configure this rule for each type of syntax.
Each of the following options can be set to "never"
, "always"
, "always-multiline"
, "only-multiline"
, or "ignore"
.
The default for each option is "never"
unless otherwise specified.
-
arrays
is for array literals and array patterns of destructuring. (e.g.let [a,] = [1,];
) -
objects
is for object literals and object patterns of destructuring. (e.g.let {a,} = {a: 1};
) -
imports
is for import declarations of ES Modules. (e.g.import {a,} from "foo";
) -
exports
is for export declarations of ES Modules. (e.g.export {a,};
) -
functions
is for function declarations and function calls. (e.g.(function(a,){ })(b,);
)
functions
is set to"ignore"
by default for consistency with the string option.
never
Examples of incorrect code for this rule with the default "never"
option:
/*eslint comma-dangle: ["error", "never"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var arr = [1,2,];
foo({
bar: "baz",
qux: "quux",
});
Examples of correct code for this rule with the default "never"
option:
/*eslint comma-dangle: ["error", "never"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var arr = [1,2];
foo({
bar: "baz",
qux: "quux"
});
always
Examples of incorrect code for this rule with the "always"
option:
/*eslint comma-dangle: ["error", "always"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var arr = [1,2];
foo({
bar: "baz",
qux: "quux"
});
Examples of correct code for this rule with the "always"
option:
/*eslint comma-dangle: ["error", "always"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var arr = [1,2,];
foo({
bar: "baz",
qux: "quux",
});
always-multiline
Examples of incorrect code for this rule with the "always-multiline"
option:
/*eslint comma-dangle: ["error", "always-multiline"]*/
var foo = {
bar: "baz",
qux: "quux"
};
var foo = { bar: "baz", qux: "quux", };
var arr = [1,2,];
var arr = [1,
2,];
var arr = [
1,
2
];
foo({
bar: "baz",
qux: "quux"
});
Examples of correct code for this rule with the "always-multiline"
option:
/*eslint comma-dangle: ["error", "always-multiline"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];
var arr = [1,
2];
var arr = [
1,
2,
];
foo({
bar: "baz",
qux: "quux",
});
only-multiline
Examples of incorrect code for this rule with the "only-multiline"
option:
/*eslint comma-dangle: ["error", "only-multiline"]*/
var foo = { bar: "baz", qux: "quux", };
var arr = [1,2,];
var arr = [1,
2,];
Examples of correct code for this rule with the "only-multiline"
option:
/*eslint comma-dangle: ["error", "only-multiline"]*/
var foo = {
bar: "baz",
qux: "quux",
};
var foo = {
bar: "baz",
qux: "quux"
};
var foo = {bar: "baz", qux: "quux"};
var arr = [1,2];
var arr = [1,
2];
var arr = [
1,
2,
];
var arr = [
1,
2
];
foo({
bar: "baz",
qux: "quux",
});
foo({
bar: "baz",
qux: "quux"
});
functions
Examples of incorrect code for this rule with the {"functions": "never"}
option:
/*eslint comma-dangle: ["error", {"functions": "never"}]*/
function foo(a, b,) {
}
foo(a, b,);
new foo(a, b,);
Examples of correct code for this rule with the {"functions": "never"}
option:
/*eslint comma-dangle: ["error", {"functions": "never"}]*/
function foo(a, b) {
}
foo(a, b);
new foo(a, b);
Examples of incorrect code for this rule with the {"functions": "always"}
option:
/*eslint comma-dangle: ["error", {"functions": "always"}]*/
function foo(a, b) {
}
foo(a, b);
new foo(a, b);
Examples of correct code for this rule with the {"functions": "always"}
option:
/*eslint comma-dangle: ["error", {"functions": "always"}]*/
function foo(a, b,) {
}
foo(a, b,);
new foo(a, b,);
When Not To Use It
You can turn this rule off if you are not concerned with dangling commas. Source: http://eslint.org/docs/rules/
Unexpected unnamed function. Open
$(function() {
- Read upRead up
- Exclude checks
Require or disallow named function
expressions (func-names)
A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:
Foo.prototype.bar = function bar() {};
Adding the second bar
in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function
in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.
Rule Details
This rule can enforce or disallow the use of named function expressions.
Options
This rule has a string option:
-
"always"
(default) requires function expressions to have a name -
"as-needed"
requires function expressions to have a name, if the name cannot be assigned automatically in an ES6 environment -
"never"
disallows named function expressions, except in recursive functions, where a name is needed
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "always"
option:
/*eslint func-names: ["error", "always"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
as-needed
ECMAScript 6 introduced a name
property on all functions. The value of name
is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name
property equal to the name of the variable. The value of name
is then used in stack traces for easier debugging.
Examples of incorrect code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Examples of correct code for this rule with the default "as-needed"
option:
/*eslint func-names: ["error", "as-needed"]*/
var bar = function() {};
(function bar() {
// ...
}())
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function bar() {};
(function bar() {
// ...
}())
Examples of correct code for this rule with the "never"
option:
/*eslint func-names: ["error", "never"]*/
Foo.prototype.bar = function() {};
(function() {
// ...
}())
Further Reading
Compatibility
- JSCS: requireAnonymousFunctions
- JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/
Block must not be padded by blank lines. Open
}
- Read upRead up
- Exclude checks
require or disallow 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 empty line padding within blocks.
Options
This rule has one option, which can be a string option or an object option.
String option:
-
"always"
(default) requires empty lines at the beginning and ending of block statements (exceptswitch
statements and classes) -
"never"
disallows empty lines at the beginning and ending of block statements (exceptswitch
statements and classes)
Object option:
-
"blocks"
require or disallow padding within block statements -
"classes"
require or disallow padding within classes -
"switches"
require or disallow padding withinswitch
statements
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the default "always"
option:
/*eslint padded-blocks: ["error", "always"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
never
Examples of incorrect code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the "never"
option:
/*eslint padded-blocks: ["error", "never"]*/
if (a) {
b();
}
if (a)
{
b();
}
blocks
Examples of incorrect code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a) { b(); }
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
if (a) {
// comment
b();
}
Examples of correct code for this rule with the { "blocks": "always" }
option:
/*eslint padded-blocks: ["error", { "blocks": "always" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
// comment
b();
}
Examples of incorrect code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
if (a) {
b();
}
if (a) {
b();
}
Examples of correct code for this rule with the { "blocks": "never" }
option:
/*eslint padded-blocks: ["error", { "blocks": "never" }]*/
if (a) {
b();
}
if (a)
{
b();
}
classes
Examples of incorrect code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "always" }
option:
/*eslint padded-blocks: ["error", { "classes": "always" }]*/
class A {
constructor(){
}
}
Examples of incorrect code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
Examples of correct code for this rule with the { "classes": "never" }
option:
/*eslint padded-blocks: ["error", { "classes": "never" }]*/
class A {
constructor(){
}
}
switches
Examples of incorrect code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "always" }
option:
/*eslint padded-blocks: ["error", { "switches": "always" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
Examples of incorrect code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
Examples of correct code for this rule with the { "switches": "never" }
option:
/*eslint padded-blocks: ["error", { "switches": "never" }]*/
switch (a) {
case 0: foo();
}
if (a) {
b();
}
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/
Import in body of module; reorder to top. Open
import Strategy from 'passport-github';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
'window' is not defined. Open
dialog.css("margin-top", Math.max(0, ($(window).height() - dialog.height()) / 2));
- 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/
Import in body of module; reorder to top. Open
import passport from 'passport';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Expected indentation of 2 spaces but found 37. Open
resave: true }));
- Read upRead up
- Exclude checks
enforce consistent indentation (indent)
There are several common guidelines which require specific indentation of nested blocks and statements, like:
function hello(indentSize, type) {
if (indentSize === 4 && type !== 'tab') {
console.log('Each next indentation will increase on 4 spaces');
}
}
These are the most common scenarios recommended in different style guides:
- Two spaces, not longer and no tabs: Google, npm, Node.js, Idiomatic, Felix
- Tabs: jQuery
- Four spaces: Crockford
Rule Details
This rule enforces a consistent indentation style. The default style is 4 spaces
.
Options
This rule has a mixed option:
For example, for 2-space indentation:
{
"indent": ["error", 2]
}
Or for tabbed indentation:
{
"indent": ["error", "tab"]
}
Examples of incorrect code for this rule with the default options:
/*eslint indent: "error"*/
if (a) {
b=c;
function foo(d) {
e=f;
}
}
Examples of correct code for this rule with the default options:
/*eslint indent: "error"*/
if (a) {
b=c;
function foo(d) {
e=f;
}
}
This rule has an object option:
-
"SwitchCase"
(default: 0) enforces indentation level forcase
clauses inswitch
statements -
"VariableDeclarator"
(default: 1) enforces indentation level forvar
declarators; can also take an object to define separate rules forvar
,let
andconst
declarations. -
"outerIIFEBody"
(default: 1) enforces indentation level for file-level IIFEs. -
"MemberExpression"
(off by default) enforces indentation level for multi-line property chains (except in variable declarations and assignments) -
"FunctionDeclaration"
takes an object to define rules for function declarations.-
parameters
(off by default) enforces indentation level for parameters in a function declaration. This can either be a number indicating indentation level, or the string"first"
indicating that all parameters of the declaration must be aligned with the first parameter. -
body
(default: 1) enforces indentation level for the body of a function declaration.
-
-
"FunctionExpression"
takes an object to define rules for function expressions.-
parameters
(off by default) enforces indentation level for parameters in a function expression. This can either be a number indicating indentation level, or the string"first"
indicating that all parameters of the expression must be aligned with the first parameter. -
body
(default: 1) enforces indentation level for the body of a function expression.
-
-
"CallExpression"
takes an object to define rules for function call expressions.-
arguments
(off by default) enforces indentation level for arguments in a call expression. This can either be a number indicating indentation level, or the string"first"
indicating that all arguments of the expression must be aligned with the first argument.
-
-
"ArrayExpression"
(default: 1) enforces indentation level for elements in arrays. It can also be set to the string"first"
, indicating that all the elements in the array should be aligned with the first element. -
"ObjectExpression"
(default: 1) enforces indentation level for properties in objects. It can be set to the string"first"
, indicating that all properties in the object should be aligned with the first property.
Level of indentation denotes the multiple of the indent specified. Example:
- Indent of 4 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 8 spaces. - Indent of 2 spaces with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 4 spaces. - Indent of 2 spaces with
VariableDeclarator
set to{"var": 2, "let": 2, "const": 3}
will indent the multi-line variable declarations with 4 spaces forvar
andlet
, 6 spaces forconst
statements. - Indent of tab with
VariableDeclarator
set to2
will indent the multi-line variable declarations with 2 tabs. - Indent of 2 spaces with
SwitchCase
set to0
will not indentcase
clauses with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to1
will indentcase
clauses with 2 spaces with respect toswitch
statements. - Indent of 2 spaces with
SwitchCase
set to2
will indentcase
clauses with 4 spaces with respect toswitch
statements. - Indent of tab with
SwitchCase
set to2
will indentcase
clauses with 2 tabs with respect toswitch
statements. - Indent of 2 spaces with
MemberExpression
set to0
will indent the multi-line property chains with 0 spaces. - Indent of 2 spaces with
MemberExpression
set to1
will indent the multi-line property chains with 2 spaces. - Indent of 2 spaces with
MemberExpression
set to2
will indent the multi-line property chains with 4 spaces. - Indent of 4 spaces with
MemberExpression
set to0
will indent the multi-line property chains with 0 spaces. - Indent of 4 spaces with
MemberExpression
set to1
will indent the multi-line property chains with 4 spaces. - Indent of 4 spaces with
MemberExpression
set to2
will indent the multi-line property chains with 8 spaces.
tab
Examples of incorrect code for this rule with the "tab"
option:
/*eslint indent: ["error", "tab"]*/
if (a) {
b=c;
function foo(d) {
e=f;
}
}
Examples of correct code for this rule with the "tab"
option:
/*eslint indent: ["error", "tab"]*/
if (a) {
/*tab*/b=c;
/*tab*/function foo(d) {
/*tab*//*tab*/e=f;
/*tab*/}
}
SwitchCase
Examples of incorrect code for this rule with the 2, { "SwitchCase": 1 }
options:
/*eslint indent: ["error", 2, { "SwitchCase": 1 }]*/
switch(a){
case "a":
break;
case "b":
break;
}
Examples of correct code for this rule with the 2, { "SwitchCase": 1 }
option:
/*eslint indent: ["error", 2, { "SwitchCase": 1 }]*/
switch(a){
case "a":
break;
case "b":
break;
}
VariableDeclarator
Examples of incorrect code for this rule with the 2, { "VariableDeclarator": 1 }
options:
/*eslint indent: ["error", 2, { "VariableDeclarator": 1 }]*/
/*eslint-env es6*/
var a,
b,
c;
let a,
b,
c;
const a = 1,
b = 2,
c = 3;
Examples of correct code for this rule with the 2, { "VariableDeclarator": 1 }
options:
/*eslint indent: ["error", 2, { "VariableDeclarator": 1 }]*/
/*eslint-env es6*/
var a,
b,
c;
let a,
b,
c;
const a = 1,
b = 2,
c = 3;
Examples of correct code for this rule with the 2, { "VariableDeclarator": 2 }
options:
/*eslint indent: ["error", 2, { "VariableDeclarator": 2 }]*/
/*eslint-env es6*/
var a,
b,
c;
let a,
b,
c;
const a = 1,
b = 2,
c = 3;
Examples of correct code for this rule with the 2, { "VariableDeclarator": { "var": 2, "let": 2, "const": 3 } }
options:
/*eslint indent: ["error", 2, { "VariableDeclarator": { "var": 2, "let": 2, "const": 3 } }]*/
/*eslint-env es6*/
var a,
b,
c;
let a,
b,
c;
const a = 1,
b = 2,
c = 3;
outerIIFEBody
Examples of incorrect code for this rule with the options 2, { "outerIIFEBody": 0 }
:
/*eslint indent: ["error", 2, { "outerIIFEBody": 0 }]*/
(function() {
function foo(x) {
return x + 1;
}
})();
if(y) {
console.log('foo');
}
Examples of correct code for this rule with the options 2, {"outerIIFEBody": 0}
:
/*eslint indent: ["error", 2, { "outerIIFEBody": 0 }]*/
(function() {
function foo(x) {
return x + 1;
}
})();
if(y) {
console.log('foo');
}
MemberExpression
Examples of incorrect code for this rule with the 2, { "MemberExpression": 1 }
options:
/*eslint indent: ["error", 2, { "MemberExpression": 1 }]*/
foo
.bar
.baz()
Examples of correct code for this rule with the 2, { "MemberExpression": 1 }
option:
/*eslint indent: ["error", 2, { "MemberExpression": 1 }]*/
foo
.bar
.baz();
// Any indentation is permitted in variable declarations and assignments.
var bip = aardvark.badger
.coyote;
FunctionDeclaration
Examples of incorrect code for this rule with the 2, { "FunctionDeclaration": {"body": 1, "parameters": 2} }
option:
/*eslint indent: ["error", 2, { "FunctionDeclaration": {"body": 1, "parameters": 2} }]*/
function foo(bar,
baz,
qux) {
qux();
}
Examples of correct code for this rule with the 2, { "FunctionDeclaration": {"body": 1, "parameters": 2} }
option:
/*eslint indent: ["error", 2, { "FunctionDeclaration": {"body": 1, "parameters": 2} }]*/
function foo(bar,
baz,
qux) {
qux();
}
Examples of incorrect code for this rule with the 2, { "FunctionDeclaration": {"parameters": "first"} }
option:
/*eslint indent: ["error", 2, {"FunctionDeclaration": {"parameters": "first"}}]*/
function foo(bar, baz,
qux, boop) {
qux();
}
Examples of correct code for this rule with the 2, { "FunctionDeclaration": {"parameters": "first"} }
option:
/*eslint indent: ["error", 2, {"FunctionDeclaration": {"parameters": "first"}}]*/
function foo(bar, baz,
qux, boop) {
qux();
}
FunctionExpression
Examples of incorrect code for this rule with the 2, { "FunctionExpression": {"body": 1, "parameters": 2} }
option:
/*eslint indent: ["error", 2, { "FunctionExpression": {"body": 1, "parameters": 2} }]*/
var foo = function(bar,
baz,
qux) {
qux();
}
Examples of correct code for this rule with the 2, { "FunctionExpression": {"body": 1, "parameters": 2} }
option:
/*eslint indent: ["error", 2, { "FunctionExpression": {"body": 1, "parameters": 2} }]*/
var foo = function(bar,
baz,
qux) {
qux();
}
Examples of incorrect code for this rule with the 2, { "FunctionExpression": {"parameters": "first"} }
option:
/*eslint indent: ["error", 2, {"FunctionExpression": {"parameters": "first"}}]*/
var foo = function(bar, baz,
qux, boop) {
qux();
}
Examples of correct code for this rule with the 2, { "FunctionExpression": {"parameters": "first"} }
option:
/*eslint indent: ["error", 2, {"FunctionExpression": {"parameters": "first"}}]*/
var foo = function(bar, baz,
qux, boop) {
qux();
}
CallExpression
Examples of incorrect code for this rule with the 2, { "CallExpression": {"arguments": 1} }
option:
/*eslint indent: ["error", 2, { "CallExpression": {"arguments": 1} }]*/
foo(bar,
baz,
qux
);
Examples of correct code for this rule with the 2, { "CallExpression": {"arguments": 1} }
option:
/*eslint indent: ["error", 2, { "CallExpression": {"arguments": 1} }]*/
foo(bar,
baz,
qux
);
Examples of incorrect code for this rule with the 2, { "CallExpression": {"arguments": "first"} }
option:
/*eslint indent: ["error", 2, {"CallExpression": {"arguments": "first"}}]*/
foo(bar, baz,
baz, boop, beep);
Examples of correct code for this rule with the 2, { "CallExpression": {"arguments": "first"} }
option:
/*eslint indent: ["error", 2, {"CallExpression": {"arguments": "first"}}]*/
foo(bar, baz,
baz, boop, beep);
ArrayExpression
Examples of incorrect code for this rule with the 2, { "ArrayExpression": 1 }
option:
/*eslint indent: ["error", 2, { "ArrayExpression": 1 }]*/
var foo = [
bar,
baz,
qux
];
Examples of correct code for this rule with the 2, { "ArrayExpression": 1 }
option:
/*eslint indent: ["error", 2, { "ArrayExpression": 1 }]*/
var foo = [
bar,
baz,
qux
];
Examples of incorrect code for this rule with the 2, { "ArrayExpression": "first" }
option:
/*eslint indent: ["error", 2, {"ArrayExpression": "first"}]*/
var foo = [bar,
baz,
qux
];
Examples of correct code for this rule with the 2, { "ArrayExpression": "first" }
option:
/*eslint indent: ["error", 2, {"ArrayExpression": "first"}]*/
var foo = [bar,
baz,
qux
];
ObjectExpression
Examples of incorrect code for this rule with the 2, { "ObjectExpression": 1 }
option:
/*eslint indent: ["error", 2, { "ObjectExpression": 1 }]*/
var foo = {
bar: 1,
baz: 2,
qux: 3
};
Examples of correct code for this rule with the 2, { "ObjectExpression": 1 }
option:
/*eslint indent: ["error", 2, { "ObjectExpression": 1 }]*/
var foo = {
bar: 1,
baz: 2,
qux: 3
};
Examples of incorrect code for this rule with the 2, { "ObjectExpression": "first" }
option:
/*eslint indent: ["error", 2, {"ObjectExpression": "first"}]*/
var foo = { bar: 1,
baz: 2 };
Examples of correct code for this rule with the 2, { "ObjectExpression": "first" }
option:
/*eslint indent: ["error", 2, {"ObjectExpression": "first"}]*/
var foo = { bar: 1,
baz: 2 };
Compatibility
-
JSHint:
indent
- JSCS: validateIndentation Source: http://eslint.org/docs/rules/
Expected dot to be on same line as property. Open
post('/add-interviewer').
- Read upRead up
- Exclude checks
Enforce newline before and after dot (dot-location)
JavaScript allows you to place newlines before or after a dot in a member expression.
Consistency in placing a newline before or after the dot can greatly increase readability.
var a = universe.
galaxy;
var b = universe
.galaxy;
Rule Details
This rule aims to enforce newline consistency in member expressions. This rule prevents the use of mixed newlines around the dot in a member expression.
Options
The rule takes one option, a string:
- If it is
"object"
, the dot in a member expression should be on the same line as the object portion. The default is"object"
. - If it is
"property"
, the dot in a member expression should be on the same line as the property portion.
object
The default "object"
option requires the dot to be on the same line as the object.
Examples of incorrect code for the default "object"
option:
/*eslint dot-location: ["error", "object"]*/
var foo = object
.property;
Examples of correct code for the default "object"
option:
/*eslint dot-location: ["error", "object"]*/
var foo = object.
property;
var bar = object.property;
property
The "property"
option requires the dot to be on the same line as the property.
Examples of incorrect code for the "property"
option:
/*eslint dot-location: ["error", "property"]*/
var foo = object.
property;
Examples of correct code for the "property"
option:
/*eslint dot-location: ["error", "property"]*/
var foo = object
.property;
var bar = object.property;
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of newlines before or after dots in member expressions.
Related Rules
- [newline-after-var](newline-after-var.md)
- [dot-notation](dot-notation.md) Source: http://eslint.org/docs/rules/
Expected empty line after require statement not followed by another require. Open
resave: true }));
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Absolute imports should come before relative imports. Open
import debug from 'debug';
- Read upRead up
- Exclude checks
For more information visit Source: http://eslint.org/docs/rules/
Expected dot to be on same line as property. Open
request(server).
- Read upRead up
- Exclude checks
Enforce newline before and after dot (dot-location)
JavaScript allows you to place newlines before or after a dot in a member expression.
Consistency in placing a newline before or after the dot can greatly increase readability.
var a = universe.
galaxy;
var b = universe
.galaxy;
Rule Details
This rule aims to enforce newline consistency in member expressions. This rule prevents the use of mixed newlines around the dot in a member expression.
Options
The rule takes one option, a string:
- If it is
"object"
, the dot in a member expression should be on the same line as the object portion. The default is"object"
. - If it is
"property"
, the dot in a member expression should be on the same line as the property portion.
object
The default "object"
option requires the dot to be on the same line as the object.
Examples of incorrect code for the default "object"
option:
/*eslint dot-location: ["error", "object"]*/
var foo = object
.property;
Examples of correct code for the default "object"
option:
/*eslint dot-location: ["error", "object"]*/
var foo = object.
property;
var bar = object.property;
property
The "property"
option requires the dot to be on the same line as the property.
Examples of incorrect code for the "property"
option:
/*eslint dot-location: ["error", "property"]*/
var foo = object.
property;
Examples of correct code for the "property"
option:
/*eslint dot-location: ["error", "property"]*/
var foo = object
.property;
var bar = object.property;
When Not To Use It
You can turn this rule off if you are not concerned with the consistency of newlines before or after dots in member expressions.
Related Rules
- [newline-after-var](newline-after-var.md)
- [dot-notation](dot-notation.md) Source: http://eslint.org/docs/rules/
Expected parentheses around arrow function argument having a body with curly braces. Open
it('should send 404 if try to get unknown page', done => {
- Read upRead up
- Exclude checks
Require parens in arrow function arguments (arrow-parens)
Arrow functions can omit parentheses when they have exactly one parameter. In all other cases the parameter(s) must be wrapped in parentheses. This rule enforces the consistent use of parentheses in arrow functions.
Rule Details
This rule enforces parentheses around arrow function parameters regardless of arity. For example:
/*eslint-env es6*/
// Bad
a => {}
// Good
(a) => {}
Following this style will help you find arrow functions (=>
) which may be mistakenly included in a condition
when a comparison such as >=
was the intent.
/*eslint-env es6*/
// Bad
if (a => 2) {
}
// Good
if (a >= 2) {
}
The rule can also be configured to discourage the use of parens when they are not required:
/*eslint-env es6*/
// Bad
(a) => {}
// Good
a => {}
Options
This rule has a string option and an object one.
String options are:
-
"always"
(default) requires parens around arguments in all cases. -
"as-needed"
allows omitting parens when there is only one argument.
Object properties for variants of the "as-needed"
option:
-
"requireForBlockBody": true
modifies the as-needed rule in order to require parens if the function body is in an instructions block (surrounded by braces).
always
Examples of incorrect code for this rule with the default "always"
option:
/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/
a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => a);
a(foo => { if (true) {} });
Examples of correct code for this rule with the default "always"
option:
/*eslint arrow-parens: ["error", "always"]*/
/*eslint-env es6*/
() => {};
(a) => {};
(a) => a;
(a) => {'\n'}
a.then((foo) => {});
a.then((foo) => { if (true) {} });
If Statements
One of benefits of this option is that it prevents the incorrect use of arrow functions in conditionals:
/*eslint-env es6*/
var a = 1;
var b = 2;
// ...
if (a => b) {
console.log('bigger');
} else {
console.log('smaller');
}
// outputs 'bigger', not smaller as expected
The contents of the if
statement is an arrow function, not a comparison.
If the arrow function is intentional, it should be wrapped in parens to remove ambiguity.
/*eslint-env es6*/
var a = 1;
var b = 0;
// ...
if ((a) => b) {
console.log('truthy value returned');
} else {
console.log('falsey value returned');
}
// outputs 'truthy value returned'
The following is another example of this behavior:
/*eslint-env es6*/
var a = 1, b = 2, c = 3, d = 4;
var f = a => b ? c: d;
// f = ?
f
is an arrow function which takes a
as an argument and returns the result of b ? c: d
.
This should be rewritten like so:
/*eslint-env es6*/
var a = 1, b = 2, c = 3, d = 4;
var f = (a) => b ? c: d;
as-needed
Examples of incorrect code for this rule with the "as-needed"
option:
/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/
(a) => {};
(a) => a;
(a) => {'\n'};
a.then((foo) => {});
a.then((foo) => a);
a((foo) => { if (true) {} });
Examples of correct code for this rule with the "as-needed"
option:
/*eslint arrow-parens: ["error", "as-needed"]*/
/*eslint-env es6*/
() => {};
a => {};
a => a;
a => {'\n'};
a.then(foo => {});
a.then(foo => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;
requireForBlockBody
Examples of incorrect code for the { "requireForBlockBody": true }
option:
/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/
(a) => a;
a => {};
a => {'\n'};
a.map((x) => x * x);
a.map(x => {
return x * x;
});
a.then(foo => {});
Examples of correct code for the { "requireForBlockBody": true }
option:
/*eslint arrow-parens: [2, "as-needed", { "requireForBlockBody": true }]*/
/*eslint-env es6*/
(a) => {};
(a) => {'\n'};
a => ({});
() => {};
a => a;
a.then((foo) => {});
a.then((foo) => { if (true) {} });
a((foo) => { if (true) {} });
(a, b, c) => a;
(a = 10) => a;
([a, b]) => a;
({a, b}) => a;
Further Reading
- The
"as-needed", { "requireForBlockBody": true }
rule is directly inspired by the Airbnb JS Style Guide. Source: http://eslint.org/docs/rules/