For more information visit Source: http://eslint.org/docs/rules/

This cops checks the indentation of the first key in a hash literal where the opening brace and the first key are on separate lines. The other keys' indentations are handled by the AlignHash cop.

By default, Hash literals that are arguments in a method call with parentheses, and where the opening curly brace of the hash is on the same line as the opening parenthesis of the method call, shall have their first key indented one step (two spaces) more than the position inside the opening parenthesis.

Other hash literals shall have their first key indented one step more than the start of the line where the opening curly brace is.

This default style is called 'specialinsideparentheses'. Alternative styles are 'consistent' and 'align_braces'. Here are examples:

Example: EnforcedStyle: specialinsideparentheses (default)

# The `special_inside_parentheses` style enforces that the first key
# in a hash literal where the opening brace and the first key are on
# separate lines is indented one step (two spaces) more than the
# position inside the opening parentheses.

# bad
hash = {
  key: :value
}
and_in_a_method_call({
  no: :difference
                     })

# good
special_inside_parentheses
hash = {
  key: :value
}
but_in_a_method_call({
                       its_like: :this
                     })

Example: EnforcedStyle: consistent

# The `consistent` style enforces that the first key in a hash
# literal where the opening brace and the first key are on
# seprate lines is indented the same as a hash literal which is not
# defined inside a method call.

# bad
hash = {
  key: :value
}
but_in_a_method_call({
                       its_like: :this
                      })

# good
hash = {
  key: :value
}
and_in_a_method_call({
  no: :difference
})

Example: EnforcedStyle: align_braces

# The `align_brackets` style enforces that the opening and closing
# braces are indented to the same position.

# bad
and_now_for_something = {
                          completely: :different
}

# good
and_now_for_something = {
                          completely: :different
                        }

Here we check if the parameters on a multi-line method call or definition are aligned.

Example: EnforcedStyle: withfirstparameter (default)

# good

foo :bar,
    :baz

# bad

foo :bar,
  :baz

Example: EnforcedStyle: withfixedindentation

# good

foo :bar,
  :baz

# bad

foo :bar,
    :baz

This cops checks for indentation that doesn't use the specified number of spaces.

See also the IndentationConsistency cop which is the companion to this one.

Example:

# bad
class A
 def test
  puts 'hello'
 end
end

# good
class A
  def test
    puts 'hello'
  end
end

Example: IgnoredPatterns: ['^\s*module']

# bad
module A
class B
  def test
  puts 'hello'
  end
end
end

# good
module A
class B
  def test
    puts 'hello'
  end
end
end

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

This cops checks for indentation that doesn't use the specified number of spaces.

See also the IndentationConsistency cop which is the companion to this one.

Example:

# bad
class A
 def test
  puts 'hello'
 end
end

# good
class A
  def test
    puts 'hello'
  end
end

Example: IgnoredPatterns: ['^\s*module']

# bad
module A
class B
  def test
  puts 'hello'
  end
end
end

# good
module A
class B
  def test
    puts 'hello'
  end
end
end

This cops checks for two or more consecutive blank lines.

Example:

# bad - It has two empty lines.
some_method
# one empty line
# two empty lines
some_method

# good
some_method
# one empty line
some_method

Here we check if the parameters on a multi-line method call or definition are aligned.

Example: EnforcedStyle: withfirstparameter (default)

# good

foo :bar,
    :baz

# bad

foo :bar,
  :baz

Example: EnforcedStyle: withfixedindentation

# good

foo :bar,
  :baz

# bad

foo :bar,
    :baz

disallow variable redeclaration (no-redeclare)

In JavaScript, it's possible to redeclare the same variable name using var. This can lead to confusion as to where the variable is actually declared and initialized.

Rule Details

This rule is aimed at eliminating variables that have multiple declarations in the same scope.

Examples of incorrect code for this rule:

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

var a = 3;
var a = 10;

Examples of correct code for this rule:

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

var a = 3;
// ...
a = 10;

Options

This rule takes one optional argument, an object with a boolean property "builtinGlobals". It defaults to false. If set to true, this rule also checks redeclaration of built-in globals, such as Object, Array, Number...

builtinGlobals

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

/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/

var Object = 0;

Examples of incorrect code for the { "builtinGlobals": true } option and the browser environment:

/*eslint no-redeclare: ["error", { "builtinGlobals": true }]*/
/*eslint-env browser*/

var top = 0;

The browser environment has many built-in global variables (for example, top). Some of built-in global variables cannot be redeclared. Source: http://eslint.org/docs/rules/

disallow variable or function declarations in nested blocks (no-inner-declarations)

In JavaScript, prior to ES6, a function declaration is only allowed in the first level of a program or the body of another function, though parsers sometimes erroneously accept them elsewhere. This only applies to function declarations; named or anonymous function expressions can occur anywhere an expression is permitted.

// Good
function doSomething() { }

// Bad
if (test) {
    function doSomethingElse () { }
}

function anotherThing() {
    var fn;

    if (test) {

        // Good
        fn = function expression() { };

        // Bad
        function declaration() { }
    }
}

A variable declaration is permitted anywhere a statement can go, even nested deeply inside other blocks. This is often undesirable due to variable hoisting, and moving declarations to the root of the program or function body can increase clarity. Note that block bindings (let, const) are not hoisted and therefore they are not affected by this rule.

/*eslint-env es6*/

// Good
var foo = 42;

// Good
if (foo) {
    let bar1;
}

// Bad
while (test) {
    var bar2;
}

function doSomething() {
    // Good
    var baz = true;

    // Bad
    if (baz) {
        var quux;
    }
}

Rule Details

This rule requires that function declarations and, optionally, variable declarations be in the root of a program or the body of a function.

Options

This rule has a string option:

• "functions" (default) disallows function declarations in nested blocks
• "both" disallows function and var declarations in nested blocks

functions

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

/*eslint no-inner-declarations: "error"*/

if (test) {
    function doSomething() { }
}

function doSomethingElse() {
    if (test) {
        function doAnotherThing() { }
    }
}

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

/*eslint no-inner-declarations: "error"*/

function doSomething() { }

function doSomethingElse() {
    function doAnotherThing() { }
}

if (test) {
    asyncCall(id, function (err, data) { });
}

var fn;
if (test) {
    fn = function fnExpression() { };
}

both

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

/*eslint no-inner-declarations: ["error", "both"]*/

if (test) {
    var foo = 42;
}

function doAnotherThing() {
    if (test) {
        var bar = 81;
    }
}

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

/*eslint no-inner-declarations: "error"*/
/*eslint-env es6*/

var bar = 42;

if (test) {
    let baz = 43;
}

function doAnotherThing() {
    var baz = 81;
}

When Not To Use It

The function declaration portion rule will be rendered obsolete when block-scoped functions land in ES6, but until then, it should be left on to enforce valid constructions. Disable checking variable declarations when using [block-scoped-var](block-scoped-var.md) or if declaring variables in nested blocks is acceptable despite hoisting. Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

Check that the keys, separators, and values of a multi-line hash literal are aligned according to configuration. The configuration options are:

- key (left align keys)
- separator (align hash rockets and colons, right align keys)
- table (left align keys, hash rockets, and values)

The treatment of hashes passed as the last argument to a method call can also be configured. The options are:

- always_inspect
- always_ignore
- ignore_implicit (without curly braces)
- ignore_explicit (with curly braces)

Example:

# EnforcedHashRocketStyle: key (default)
# EnforcedColonStyle: key (default)

# good
{
  foo: bar,
  ba: baz
}
{
  :foo => bar,
  :ba => baz
}

# bad
{
  foo: bar,
   ba: baz
}
{
  :foo => bar,
   :ba => baz
}

Example:

# EnforcedHashRocketStyle: separator
# EnforcedColonStyle: separator

#good
{
  foo: bar,
   ba: baz
}
{
  :foo => bar,
   :ba => baz
}

#bad
{
  foo: bar,
  ba: baz
}
{
  :foo => bar,
  :ba => baz
}
{
  :foo => bar,
  :ba  => baz
}

Example:

# EnforcedHashRocketStyle: table
# EnforcedColonStyle: table

#good
{
  foo: bar,
  ba:  baz
}
{
  :foo => bar,
  :ba  => baz
}

#bad
{
  foo: bar,
  ba: baz
}
{
  :foo => bar,
   :ba => baz
}

This cop checks for the use of a method, the result of which would be a literal, like an empty array, hash or string.

Example:

# bad
a = Array.new
h = Hash.new
s = String.new

# good
a = []
h = {}
s = ''