huridocs/uwazi

title: max-lines ruletype: suggestion relatedrules: - complexity - max-depth - max-lines-per-function - max-nested-callbacks - max-params - max-statements further_reading:

- https://web.archive.org/web/20160725154648/http://www.mind2b.com/component/content/article/24-software-module-size-and-file-size

Some people consider large files a code smell. Large files tend to do a lot of things and can make it hard following what's going. While there is not an objective maximum number of lines considered acceptable in a file, most people would agree it should not be in the thousands. Recommendations usually range from 100 to 500 lines.

Rule Details

This rule enforces a maximum number of lines per file, in order to aid in maintainability and reduce complexity.

Please note that most editors show an additional empty line at the end if the file ends with a line break. This rule does not count that extra line.

Options

This rule has a number or object option:

• "max" (default 300) enforces a maximum number of lines in a file

• "skipBlankLines": true ignore lines made up purely of whitespace.

• "skipComments": true ignore lines containing just comments

max

Examples of incorrect code for this rule with a max value of 2:

::: incorrect

/*eslint max-lines: ["error", 2]*/
var a,
    b,
    c;

:::

::: incorrect

/*eslint max-lines: ["error", 2]*/

var a,
    b,c;

:::

::: incorrect

/*eslint max-lines: ["error", 2]*/
// a comment
var a,
    b,c;

:::

Examples of correct code for this rule with a max value of 2:

::: correct

/*eslint max-lines: ["error", 2]*/
var a,
    b, c;

:::

::: correct

/*eslint max-lines: ["error", 2]*/

var a, b, c;

:::

::: correct

/*eslint max-lines: ["error", 2]*/
// a comment
var a, b, c;

:::

skipBlankLines

Examples of incorrect code for this rule with the { "skipBlankLines": true } option:

::: incorrect

/*eslint max-lines: ["error", {"max": 2, "skipBlankLines": true}]*/

var a,
    b,
    c;

:::

Examples of correct code for this rule with the { "skipBlankLines": true } option:

::: correct

/*eslint max-lines: ["error", {"max": 2, "skipBlankLines": true}]*/

var a,
    b, c;

:::

skipComments

Examples of incorrect code for this rule with the { "skipComments": true } option:

::: incorrect

/*eslint max-lines: ["error", {"max": 2, "skipComments": true}]*/
// a comment
var a,
    b,
    c;

:::

Examples of correct code for this rule with the { "skipComments": true } option:

::: correct

/*eslint max-lines: ["error", {"max": 2, "skipComments": true}]*/
// a comment
var a,
    b, c;

:::

When Not To Use It

You can turn this rule off if you are not concerned with the number of lines in your files.

Compatibility

• JSCS: maximumNumberOfLines Source: http://eslint.org/docs/rules/

title: max-params ruletype: suggestion relatedrules: - complexity - max-depth - max-len - max-lines - max-lines-per-function - max-nested-callbacks

- max-statements

Functions that take numerous parameters can be difficult to read and write because it requires the memorization of what each parameter is, its type, and the order they should appear in. As a result, many coders adhere to a convention that caps the number of parameters a function can take.

function foo (bar, baz, qux, qxx) { // four parameters, may be too many
    doSomething();
}

Rule Details

This rule enforces a maximum number of parameters allowed in function definitions.

Options

This rule has a number or object option:

• "max" (default 3) enforces a maximum number of parameters in function definitions

Deprecated: The object property maximum is deprecated; please use the object property max instead.

max

Examples of incorrect code for this rule with the default { "max": 3 } option:

:::incorrect

/*eslint max-params: ["error", 3]*/
/*eslint-env es6*/

function foo (bar, baz, qux, qxx) {
    doSomething();
}

let foo = (bar, baz, qux, qxx) => {
    doSomething();
};

:::

Examples of correct code for this rule with the default { "max": 3 } option:

:::correct

/*eslint max-params: ["error", 3]*/
/*eslint-env es6*/

function foo (bar, baz, qux) {
    doSomething();
}

let foo = (bar, baz, qux) => {
    doSomething();
};

::: Source: http://eslint.org/docs/rules/

title: max-params ruletype: suggestion relatedrules: - complexity - max-depth - max-len - max-lines - max-lines-per-function - max-nested-callbacks

- max-statements

Functions that take numerous parameters can be difficult to read and write because it requires the memorization of what each parameter is, its type, and the order they should appear in. As a result, many coders adhere to a convention that caps the number of parameters a function can take.

function foo (bar, baz, qux, qxx) { // four parameters, may be too many
    doSomething();
}

Rule Details

This rule enforces a maximum number of parameters allowed in function definitions.

Options

This rule has a number or object option:

• "max" (default 3) enforces a maximum number of parameters in function definitions

Deprecated: The object property maximum is deprecated; please use the object property max instead.

max

Examples of incorrect code for this rule with the default { "max": 3 } option:

:::incorrect

/*eslint max-params: ["error", 3]*/
/*eslint-env es6*/

function foo (bar, baz, qux, qxx) {
    doSomething();
}

let foo = (bar, baz, qux, qxx) => {
    doSomething();
};

:::

Examples of correct code for this rule with the default { "max": 3 } option:

:::correct

/*eslint max-params: ["error", 3]*/
/*eslint-env es6*/

function foo (bar, baz, qux) {
    doSomething();
}

let foo = (bar, baz, qux) => {
    doSomething();
};

::: Source: http://eslint.org/docs/rules/

title: consistent-return

rule_type: suggestion

Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

• it does not execute a return statement before it exits
• it executes return which does not specify a value explicitly
• it executes return undefined
• it executes return void followed by an expression (for example, a function call)
• it executes return followed by any other expression which evaluates to undefined

If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

• a code path through the function returns a Boolean value true
• another code path does not return a value explicitly, therefore returns undefined implicitly

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

Rule Details

This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

Examples of incorrect code for this rule:

::: incorrect

/*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

:::

Examples of correct code for this rule:

::: correct

/*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

:::

Options

This rule has an object option:

• "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
• "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

treatUndefinedAsUnspecified

Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

::: incorrect

/*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

:::

Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

::: incorrect

/*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

:::

Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

::: correct

/*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

:::

When Not To Use It

If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

title: no-param-reassign ruletype: suggestion furtherreading:

- https://spin.atomicobject.com/2011/04/10/javascript-don-t-reassign-your-function-arguments/

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object when not in strict mode (see When Not To Use It below). Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

::: incorrect

/*eslint no-param-reassign: "error"*/

function foo(bar) {
    bar = 13;
}

function foo(bar) {
    bar++;
}

function foo(bar) {
    for (bar in baz) {}
}

function foo(bar) {
    for (bar of baz) {}
}

:::

Examples of correct code for this rule:

::: correct

/*eslint no-param-reassign: "error"*/

function foo(bar) {
    var baz = bar;
}

:::

Options

This rule takes one option, an object, with a boolean property "props", and arrays "ignorePropertyModificationsFor" and "ignorePropertyModificationsForRegex". "props" is false by default. If "props" is set to true, this rule warns against the modification of parameter properties unless they're included in "ignorePropertyModificationsFor" or "ignorePropertyModificationsForRegex", which is an empty array by default.

props

Examples of correct code for the default { "props": false } option:

::: correct

/*eslint no-param-reassign: ["error", { "props": false }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

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

::: incorrect

/*eslint no-param-reassign: ["error", { "props": true }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

::: correct

/*eslint no-param-reassign: ["error", { "props": true, "ignorePropertyModificationsFor": ["bar"] }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsForRegex" set:

::: correct

/*eslint no-param-reassign: ["error", { "props": true, "ignorePropertyModificationsForRegex": ["^bar"] }]*/

function foo(barVar) {
    barVar.prop = "value";
}

function foo(barrito) {
    delete barrito.aaa;
}

function foo(bar_) {
    bar_.aaa++;
}

function foo(barBaz) {
    for (barBaz.aaa in baz) {}
}

function foo(barBaz) {
    for (barBaz.aaa of baz) {}
}

:::

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

Strict mode code doesn't sync indices of the arguments object with each parameter binding. Therefore, this rule is not necessary to protect against arguments object mutation in ESM modules or other strict mode functions. 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/

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