core/layout/admin/res/js/core.alert.js

Summary

Maintainability
A
2 hrs
Test Coverage

Function Alert has 47 lines of code (exceeds 25 allowed). Consider refactoring.
Open

AC.Core.Alert = function() {

    var elements = $('#alert-wrapper');
    var textContainer = $('#alert-text');

Severity: Minor
Found in core/layout/admin/res/js/core.alert.js - About 1 hr to fix

    Function Alert has a Cognitive Complexity of 8 (exceeds 5 allowed). Consider refactoring.
    Open

    AC.Core.Alert = function() {
    
        var elements = $('#alert-wrapper');
        var textContainer = $('#alert-text');
    
    
    Severity: Minor
    Found in core/layout/admin/res/js/core.alert.js - About 45 mins 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

    Wrap an immediate function invocation in parentheses.
    Open

    AC.Core.Alert = function() {

    Require IIFEs to be Wrapped (wrap-iife)

    You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.

    // function expression could be unwrapped
    var x = function () { return { y: 1 };}();
    
    // function declaration must be wrapped
    function () { /* side effects */ }(); // SyntaxError

    Rule Details

    This rule requires all immediately-invoked function expressions to be wrapped in parentheses.

    Options

    This rule has two options, a string option and an object option.

    String option:

    • "outside" enforces always wrapping the call expression. The default is "outside".
    • "inside" enforces always wrapping the function expression.
    • "any" enforces always wrapping, but allows either style.

    Object option:

    • "functionPrototypeMethods": true additionally enforces wrapping function expressions invoked using .call and .apply. The default is false.

    outside

    Examples of incorrect code for the default "outside" option:

    /*eslint wrap-iife: ["error", "outside"]*/
    
    var x = function () { return { y: 1 };}(); // unwrapped
    var x = (function () { return { y: 1 };})(); // wrapped function expression

    Examples of correct code for the default "outside" option:

    /*eslint wrap-iife: ["error", "outside"]*/
    
    var x = (function () { return { y: 1 };}()); // wrapped call expression

    inside

    Examples of incorrect code for the "inside" option:

    /*eslint wrap-iife: ["error", "inside"]*/
    
    var x = function () { return { y: 1 };}(); // unwrapped
    var x = (function () { return { y: 1 };}()); // wrapped call expression

    Examples of correct code for the "inside" option:

    /*eslint wrap-iife: ["error", "inside"]*/
    
    var x = (function () { return { y: 1 };})(); // wrapped function expression

    any

    Examples of incorrect code for the "any" option:

    /*eslint wrap-iife: ["error", "any"]*/
    
    var x = function () { return { y: 1 };}(); // unwrapped

    Examples of correct code for the "any" option:

    /*eslint wrap-iife: ["error", "any"]*/
    
    var x = (function () { return { y: 1 };}()); // wrapped call expression
    var x = (function () { return { y: 1 };})(); // wrapped function expression

    functionPrototypeMethods

    Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true } options:

    /* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
    
    var x = function(){ foo(); }()
    var x = (function(){ foo(); }())
    var x = function(){ foo(); }.call(bar)
    var x = (function(){ foo(); }.call(bar))

    Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true } options:

    /* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */
    
    var x = (function(){ foo(); })()
    var x = (function(){ foo(); }).call(bar)

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

    Unnecessary semicolon.
    Open

    ;

    disallow unnecessary semicolons (no-extra-semi)

    Typing mistakes and misunderstandings about where semicolons are required can lead to semicolons that are unnecessary. While not technically an error, extra semicolons can cause confusion when reading code.

    Rule Details

    This rule disallows unnecessary semicolons.

    Examples of incorrect code for this rule:

    /*eslint no-extra-semi: "error"*/
    
    var x = 5;;
    
    function foo() {
        // code
    };

    Examples of correct code for this rule:

    /*eslint no-extra-semi: "error"*/
    
    var x = 5;
    
    var foo = function() {
        // code
    };

    When Not To Use It

    If you intentionally use extra semicolons then you can disable this rule.

    Related Rules

    Expected return with your callback function.
    Open

                    callback();

    Enforce Return After Callback (callback-return)

    The callback pattern is at the heart of most I/O and event-driven programming in JavaScript.

    function doSomething(err, callback) {
        if (err) {
            return callback(err);
        }
        callback();
    }

    To prevent calling the callback multiple times it is important to return anytime the callback is triggered outside of the main function body. Neglecting this technique often leads to issues where you do something more than once. For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw a Can't render headers after they are sent to the client. error.

    Rule Details

    This rule is aimed at ensuring that callbacks used outside of the main function block are always part-of or immediately preceding a return statement. This rule decides what is a callback based on the name of the function being called.

    Options

    The rule takes a single option - an array of possible callback names - which may include object methods. The default callback names are callback, cb, next.

    Default callback names

    Examples of incorrect code for this rule with the default ["callback", "cb", "next"] option:

    /*eslint callback-return: "error"*/
    
    function foo(err, callback) {
        if (err) {
            callback(err);
        }
        callback();
    }

    Examples of correct code for this rule with the default ["callback", "cb", "next"] option:

    /*eslint callback-return: "error"*/
    
    function foo(err, callback) {
        if (err) {
            return callback(err);
        }
        callback();
    }

    Supplied callback names

    Examples of incorrect code for this rule with the option ["done", "send.error", "send.success"]:

    /*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
    
    function foo(err, done) {
        if (err) {
            done(err);
        }
        done();
    }
    
    function bar(err, send) {
        if (err) {
            send.error(err);
        }
        send.success();
    }

    Examples of correct code for this rule with the option ["done", "send.error", "send.success"]:

    /*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/
    
    function foo(err, done) {
        if (err) {
            return done(err);
        }
        done();
    }
    
    function bar(err, send) {
        if (err) {
            return send.error(err);
        }
        send.success();
    }

    Known Limitations

    Because it is difficult to understand the meaning of a program through static analysis, this rule has limitations:

    • false negatives when this rule reports correct code, but the program calls the callback more than one time (which is incorrect behavior)
    • false positives when this rule reports incorrect code, but the program calls the callback only one time (which is correct behavior)

    Passing the callback by reference

    The static analysis of this rule does not detect that the program calls the callback if it is an argument of a function (for example, setTimeout).

    Example of a false negative when this rule reports correct code:

    /*eslint callback-return: "error"*/
    
    function foo(err, callback) {
        if (err) {
            setTimeout(callback, 0); // this is bad, but WILL NOT warn
        }
        callback();
    }

    Triggering the callback within a nested function

    The static analysis of this rule does not detect that the program calls the callback from within a nested function or an immediately-invoked function expression (IIFE).

    Example of a false negative when this rule reports correct code:

    /*eslint callback-return: "error"*/
    
    function foo(err, callback) {
        if (err) {
            process.nextTick(function() {
                return callback(); // this is bad, but WILL NOT warn
            });
        }
        callback();
    }

    If/else statements

    The static analysis of this rule does not detect that the program calls the callback only one time in each branch of an if statement.

    Example of a false positive when this rule reports incorrect code:

    /*eslint callback-return: "error"*/
    
    function foo(err, callback) {
        if (err) {
            callback(err); // this is fine, but WILL warn
        } else {
            callback();    // this is fine, but WILL warn
        }
    }

    When Not To Use It

    There are some cases where you might want to call a callback function more than once. In those cases this rule may lead to incorrect behavior. In those cases you may want to reserve a special name for those callbacks and not include that in the list of callbacks that trigger warnings.

    Further Reading

    Related Rules

    There are no issues that match your filters.

    Category
    Status