fbi-cde/crime-data-frontend

View on GitHub
src/components/graph/StackedBarChart.js

Summary

Maintainability
A
0 mins
Test Coverage

Function render has 117 lines of code (exceeds 25 allowed). Consider refactoring.
Invalid

  render() {
    const { colors, margin, size, data, year, until } = this.props

    let fitleredDataByYear
    if (year !== 2 && year !== 5 && year !== 10) {
Severity: Major
Found in src/components/graph/StackedBarChart.js - About 4 hrs to fix

    Function render has a Cognitive Complexity of 22 (exceeds 5 allowed). Consider refactoring.
    Invalid

      render() {
        const { colors, margin, size, data, year, until } = this.props
    
        let fitleredDataByYear
        if (year !== 2 && year !== 5 && year !== 10) {
    Severity: Minor
    Found in src/components/graph/StackedBarChart.js - About 3 hrs to fix

    Cognitive Complexity

    Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

    A method's cognitive complexity is based on a few simple rules:

    • Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
    • Code is considered more complex for each "break in the linear flow of the code"
    • Code is considered more complex when "flow breaking structures are nested"

    Further reading

    The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype.
    Invalid

          for (const i in Array.from(keys)) {

    Require Guarding for-in (guard-for-in)

    Looping over objects with a for in loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.

    for (key in foo) {
        doSomething(key);
    }

    Note that simply checking foo.hasOwnProperty(key) is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).

    Rule Details

    This rule is aimed at preventing unexpected behavior that could arise from using a for in loop without filtering the results in the loop. As such, it will warn when for in loops do not filter their results with an if statement.

    Examples of incorrect code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        doSomething(key);
    }

    Examples of correct code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        if (Object.prototype.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
        if ({}.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
    }

    Related Rules

    • [no-prototype-builtins](no-prototype-builtins.md)

    Further Reading

    The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype.
    Invalid

          for (const i in fitleredDataByYear) {

    Require Guarding for-in (guard-for-in)

    Looping over objects with a for in loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.

    for (key in foo) {
        doSomething(key);
    }

    Note that simply checking foo.hasOwnProperty(key) is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).

    Rule Details

    This rule is aimed at preventing unexpected behavior that could arise from using a for in loop without filtering the results in the loop. As such, it will warn when for in loops do not filter their results with an if statement.

    Examples of incorrect code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        doSomething(key);
    }

    Examples of correct code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        if (Object.prototype.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
        if ({}.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
    }

    Related Rules

    • [no-prototype-builtins](no-prototype-builtins.md)

    Further Reading

    for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.
    Invalid

        for (const d in fitleredDataByYear) {

    disallow specified syntax (no-restricted-syntax)

    JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

    Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

    You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.

    Rule Details

    This rule disallows specified (that is, user-defined) syntax.

    Options

    This rule takes a list of strings, where each string is an AST selector:

    {
        "rules": {
            "no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
        }
    }

    Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:

    {
        "rules": {
            "no-restricted-syntax": [
                "error",
                {
                    "selector": "FunctionExpression",
                    "message": "Function expressions are not allowed."
                },
                {
                    "selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
                    "message": "setTimeout must always be invoked with two arguments."
                }
            ]
        }
    }

    If a custom message is specified with the message property, ESLint will use that message when reporting occurrences of the syntax specified in the selector property.

    The string and object formats can be freely mixed in the configuration as needed.

    Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    with (me) {
        dontMess();
    }
    
    var doSomething = function () {};
    
    foo in bar;

    Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    me.dontMess();
    
    function doSomething() {};
    
    foo instanceof bar;

    When Not To Use It

    If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.

    Related Rules

    • [no-alert](no-alert.md)
    • [no-console](no-console.md)
    • [no-debugger](no-debugger.md)
    • [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/

    'lookup' is assigned a value but never used.
    Invalid

        const lookup = Object.assign(

    Disallow Unused Variables (no-unused-vars)

    Variables that are declared and not used anywhere in the code are most likely an error due to incomplete refactoring. Such variables take up space in the code and can lead to confusion by readers.

    Rule Details

    This rule is aimed at eliminating unused variables, functions, and parameters of functions.

    A variable is considered to be used if any of the following are true:

    • It represents a function that is called (doSomething())
    • It is read (var y = x)
    • It is passed into a function as an argument (doSomething(x))
    • It is read inside of a function that is passed to another function (doSomething(function() { foo(); }))

    A variable is not considered to be used if it is only ever assigned to (var x = 5) or declared.

    Examples of incorrect code for this rule:

    /*eslint no-unused-vars: "error"*/
    /*global some_unused_var*/
    
    // It checks variables you have defined as global
    some_unused_var = 42;
    
    var x;
    
    // Write-only variables are not considered as used.
    var y = 10;
    y = 5;
    
    // A read for a modification of itself is not considered as used.
    var z = 0;
    z = z + 1;
    
    // By default, unused arguments cause warnings.
    (function(foo) {
        return 5;
    })();
    
    // Unused recursive functions also cause warnings.
    function fact(n) {
        if (n < 2) return 1;
        return n * fact(n - 1);
    }
    
    // When a function definition destructures an array, unused entries from the array also cause warnings.
    function getY([x, y]) {
        return y;
    }

    Examples of correct code for this rule:

    /*eslint no-unused-vars: "error"*/
    
    var x = 10;
    alert(x);
    
    // foo is considered used here
    myFunc(function foo() {
        // ...
    }.bind(this));
    
    (function(foo) {
        return foo;
    })();
    
    var myFunc;
    myFunc = setTimeout(function() {
        // myFunc is considered used
        myFunc();
    }, 50);
    
    // Only the second argument from the descructured array is used.
    function getY([, y]) {
        return y;
    }

    exported

    In environments outside of CommonJS or ECMAScript modules, you may use var to create a global variable that may be used by other scripts. You can use the /* exported variableName */ comment block to indicate that this variable is being exported and therefore should not be considered unused.

    Note that /* exported */ has no effect for any of the following:

    • when the environment is node or commonjs
    • when parserOptions.sourceType is module
    • when ecmaFeatures.globalReturn is true

    The line comment // exported variableName will not work as exported is not line-specific.

    Examples of correct code for /* exported variableName */ operation:

    /* exported global_var */
    
    var global_var = 42;

    Options

    This rule takes one argument which can be a string or an object. The string settings are the same as those of the vars property (explained below).

    By default this rule is enabled with all option for variables and after-used for arguments.

    {
        "rules": {
            "no-unused-vars": ["error", { "vars": "all", "args": "after-used", "ignoreRestSiblings": false }]
        }
    }

    vars

    The vars option has two settings:

    • all checks all variables for usage, including those in the global scope. This is the default setting.
    • local checks only that locally-declared variables are used but will allow global variables to be unused.

    vars: local

    Examples of correct code for the { "vars": "local" } option:

    /*eslint no-unused-vars: ["error", { "vars": "local" }]*/
    /*global some_unused_var */
    
    some_unused_var = 42;

    varsIgnorePattern

    The varsIgnorePattern option specifies exceptions not to check for usage: variables whose names match a regexp pattern. For example, variables whose names contain ignored or Ignored.

    Examples of correct code for the { "varsIgnorePattern": "[iI]gnored" } option:

    /*eslint no-unused-vars: ["error", { "varsIgnorePattern": "[iI]gnored" }]*/
    
    var firstVarIgnored = 1;
    var secondVar = 2;
    console.log(secondVar);

    args

    The args option has three settings:

    • after-used - only the last argument must be used. This allows you, for instance, to have two named parameters to a function and as long as you use the second argument, ESLint will not warn you about the first. This is the default setting.
    • all - all named arguments must be used.
    • none - do not check arguments.

    args: after-used

    Examples of incorrect code for the default { "args": "after-used" } option:

    /*eslint no-unused-vars: ["error", { "args": "after-used" }]*/
    
    // 1 error
    // "baz" is defined but never used
    (function(foo, bar, baz) {
        return bar;
    })();

    Examples of correct code for the default { "args": "after-used" } option:

    /*eslint no-unused-vars: ["error", {"args": "after-used"}]*/
    
    (function(foo, bar, baz) {
        return baz;
    })();

    args: all

    Examples of incorrect code for the { "args": "all" } option:

    /*eslint no-unused-vars: ["error", { "args": "all" }]*/
    
    // 2 errors
    // "foo" is defined but never used
    // "baz" is defined but never used
    (function(foo, bar, baz) {
        return bar;
    })();

    args: none

    Examples of correct code for the { "args": "none" } option:

    /*eslint no-unused-vars: ["error", { "args": "none" }]*/
    
    (function(foo, bar, baz) {
        return bar;
    })();

    ignoreRestSiblings

    The ignoreRestSiblings option is a boolean (default: false). Using a Rest Property it is possible to "omit" properties from an object, but by default the sibling properties are marked as "unused". With this option enabled the rest property's siblings are ignored.

    Examples of correct code for the { "ignoreRestSiblings": true } option:

    /*eslint no-unused-vars: ["error", { "ignoreRestSiblings": true }]*/
    // 'type' is ignored because it has a rest property sibling.
    var { type, ...coords } = data;

    argsIgnorePattern

    The argsIgnorePattern option specifies exceptions not to check for usage: arguments whose names match a regexp pattern. For example, variables whose names begin with an underscore.

    Examples of correct code for the { "argsIgnorePattern": "^_" } option:

    /*eslint no-unused-vars: ["error", { "argsIgnorePattern": "^_" }]*/
    
    function foo(x, _y) {
        return x + 1;
    }
    foo();

    caughtErrors

    The caughtErrors option is used for catch block arguments validation.

    It has two settings:

    • none - do not check error objects. This is the default setting.
    • all - all named arguments must be used.

    caughtErrors: none

    Not specifying this rule is equivalent of assigning it to none.

    Examples of correct code for the { "caughtErrors": "none" } option:

    /*eslint no-unused-vars: ["error", { "caughtErrors": "none" }]*/
    
    try {
        //...
    } catch (err) {
        console.error("errors");
    }

    caughtErrors: all

    Examples of incorrect code for the { "caughtErrors": "all" } option:

    /*eslint no-unused-vars: ["error", { "caughtErrors": "all" }]*/
    
    // 1 error
    // "err" is defined but never used
    try {
        //...
    } catch (err) {
        console.error("errors");
    }

    caughtErrorsIgnorePattern

    The caughtErrorsIgnorePattern option specifies exceptions not to check for usage: catch arguments whose names match a regexp pattern. For example, variables whose names begin with a string 'ignore'.

    Examples of correct code for the { "caughtErrorsIgnorePattern": "^ignore" } option:

    /*eslint no-unused-vars: ["error", { "caughtErrorsIgnorePattern": "^ignore" }]*/
    
    try {
        //...
    } catch (ignoreErr) {
        console.error("errors");
    }

    When Not To Use It

    If you don't want to be notified about unused variables or function arguments, you can safely turn this rule off. Source: http://eslint.org/docs/rules/

    for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.
    Invalid

          for (const i in fitleredDataByYear) {

    disallow specified syntax (no-restricted-syntax)

    JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

    Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

    You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.

    Rule Details

    This rule disallows specified (that is, user-defined) syntax.

    Options

    This rule takes a list of strings, where each string is an AST selector:

    {
        "rules": {
            "no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
        }
    }

    Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:

    {
        "rules": {
            "no-restricted-syntax": [
                "error",
                {
                    "selector": "FunctionExpression",
                    "message": "Function expressions are not allowed."
                },
                {
                    "selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
                    "message": "setTimeout must always be invoked with two arguments."
                }
            ]
        }
    }

    If a custom message is specified with the message property, ESLint will use that message when reporting occurrences of the syntax specified in the selector property.

    The string and object formats can be freely mixed in the configuration as needed.

    Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    with (me) {
        dontMess();
    }
    
    var doSomething = function () {};
    
    foo in bar;

    Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    me.dontMess();
    
    function doSomething() {};
    
    foo instanceof bar;

    When Not To Use It

    If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.

    Related Rules

    • [no-alert](no-alert.md)
    • [no-console](no-console.md)
    • [no-debugger](no-debugger.md)
    • [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/

    for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.
    Invalid

          for (const m in data.keys) {

    disallow specified syntax (no-restricted-syntax)

    JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

    Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

    You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.

    Rule Details

    This rule disallows specified (that is, user-defined) syntax.

    Options

    This rule takes a list of strings, where each string is an AST selector:

    {
        "rules": {
            "no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
        }
    }

    Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:

    {
        "rules": {
            "no-restricted-syntax": [
                "error",
                {
                    "selector": "FunctionExpression",
                    "message": "Function expressions are not allowed."
                },
                {
                    "selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
                    "message": "setTimeout must always be invoked with two arguments."
                }
            ]
        }
    }

    If a custom message is specified with the message property, ESLint will use that message when reporting occurrences of the syntax specified in the selector property.

    The string and object formats can be freely mixed in the configuration as needed.

    Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    with (me) {
        dontMess();
    }
    
    var doSomething = function () {};
    
    foo in bar;

    Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    me.dontMess();
    
    function doSomething() {};
    
    foo instanceof bar;

    When Not To Use It

    If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.

    Related Rules

    • [no-alert](no-alert.md)
    • [no-console](no-console.md)
    • [no-debugger](no-debugger.md)
    • [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/

    for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.
    Invalid

          for (const i in Array.from(keys)) {

    disallow specified syntax (no-restricted-syntax)

    JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

    Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

    You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.

    Rule Details

    This rule disallows specified (that is, user-defined) syntax.

    Options

    This rule takes a list of strings, where each string is an AST selector:

    {
        "rules": {
            "no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
        }
    }

    Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:

    {
        "rules": {
            "no-restricted-syntax": [
                "error",
                {
                    "selector": "FunctionExpression",
                    "message": "Function expressions are not allowed."
                },
                {
                    "selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
                    "message": "setTimeout must always be invoked with two arguments."
                }
            ]
        }
    }

    If a custom message is specified with the message property, ESLint will use that message when reporting occurrences of the syntax specified in the selector property.

    The string and object formats can be freely mixed in the configuration as needed.

    Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    with (me) {
        dontMess();
    }
    
    var doSomething = function () {};
    
    foo in bar;

    Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    me.dontMess();
    
    function doSomething() {};
    
    foo instanceof bar;

    When Not To Use It

    If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.

    Related Rules

    • [no-alert](no-alert.md)
    • [no-console](no-console.md)
    • [no-debugger](no-debugger.md)
    • [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/

    The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype.
    Invalid

        for (const d in fitleredDataByYear) {

    Require Guarding for-in (guard-for-in)

    Looping over objects with a for in loop will include properties that are inherited through the prototype chain. This behavior can lead to unexpected items in your for loop.

    for (key in foo) {
        doSomething(key);
    }

    Note that simply checking foo.hasOwnProperty(key) is likely to cause an error in some cases; see [no-prototype-builtins](no-prototype-builtins.md).

    Rule Details

    This rule is aimed at preventing unexpected behavior that could arise from using a for in loop without filtering the results in the loop. As such, it will warn when for in loops do not filter their results with an if statement.

    Examples of incorrect code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        doSomething(key);
    }

    Examples of correct code for this rule:

    /*eslint guard-for-in: "error"*/
    
    for (key in foo) {
        if (Object.prototype.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
        if ({}.hasOwnProperty.call(foo, key)) {
            doSomething(key);
        }
    }

    Related Rules

    • [no-prototype-builtins](no-prototype-builtins.md)

    Further Reading

    for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array.
    Invalid

            for (const j in fitleredDataByYear) {

    disallow specified syntax (no-restricted-syntax)

    JavaScript has a lot of language features, and not everyone likes all of them. As a result, some projects choose to disallow the use of certain language features altogether. For instance, you might decide to disallow the use of try-catch or class, or you might decide to disallow the use of the in operator.

    Rather than creating separate rules for every language feature you want to turn off, this rule allows you to configure the syntax elements you want to restrict use of. These elements are represented by their ESTree node types. For example, a function declaration is represented by FunctionDeclaration and the with statement is represented by WithStatement. You may find the full list of AST node names you can use on GitHub and use the online parser to see what type of nodes your code consists of.

    You can also specify [AST selectors](../developer-guide/selectors) to restrict, allowing much more precise control over syntax patterns.

    Rule Details

    This rule disallows specified (that is, user-defined) syntax.

    Options

    This rule takes a list of strings, where each string is an AST selector:

    {
        "rules": {
            "no-restricted-syntax": ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"]
        }
    }

    Alternatively, the rule also accepts objects, where the selector and an optional custom message are specified:

    {
        "rules": {
            "no-restricted-syntax": [
                "error",
                {
                    "selector": "FunctionExpression",
                    "message": "Function expressions are not allowed."
                },
                {
                    "selector": "CallExpression[callee.name='setTimeout'][arguments.length!=2]",
                    "message": "setTimeout must always be invoked with two arguments."
                }
            ]
        }
    }

    If a custom message is specified with the message property, ESLint will use that message when reporting occurrences of the syntax specified in the selector property.

    The string and object formats can be freely mixed in the configuration as needed.

    Examples of incorrect code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    with (me) {
        dontMess();
    }
    
    var doSomething = function () {};
    
    foo in bar;

    Examples of correct code for this rule with the "FunctionExpression", "WithStatement", BinaryExpression[operator='in'] options:

    /* eslint no-restricted-syntax: ["error", "FunctionExpression", "WithStatement", "BinaryExpression[operator='in']"] */
    
    me.dontMess();
    
    function doSomething() {};
    
    foo instanceof bar;

    When Not To Use It

    If you don't want to restrict your code from using any JavaScript features or syntax, you should not use this rule.

    Related Rules

    • [no-alert](no-alert.md)
    • [no-console](no-console.md)
    • [no-debugger](no-debugger.md)
    • [no-restricted-properties](no-restricted-properties.md) Source: http://eslint.org/docs/rules/

    The object literal notation {} is preferrable.
    Open

            const object = new Object()

    disallow Object constructors (no-new-object)

    The Object constructor is used to create new generic objects in JavaScript, such as:

    var myObject = new Object();

    However, this is no different from using the more concise object literal syntax:

    var myObject = {};

    For this reason, many prefer to always use the object literal syntax and never use the Object constructor.

    While there are no performance differences between the two approaches, the byte savings and conciseness of the object literal form is what has made it the de facto way of creating new objects.

    Rule Details

    This rule disallows Object constructors.

    Examples of incorrect code for this rule:

    /*eslint no-new-object: "error"*/
    
    var myObject = new Object();
    
    var myObject = new Object;

    Examples of correct code for this rule:

    /*eslint no-new-object: "error"*/
    
    var myObject = new CustomObject();
    
    var myObject = {};

    When Not To Use It

    If you wish to allow the use of the Object constructor, you can safely turn this rule off.

    Related Rules

    There are no issues that match your filters.

    Category
    Status