kai-jacobsen/kontentblocks

View on GitHub
js/src/shared/ModuleBrowser/ModuleBrowserController.js

Summary

Maintainability
A
1 hr
Test Coverage

Function createModule has 27 lines of code (exceeds 25 allowed). Consider refactoring.
Open

  createModule: function (module) {
    var Area, data;
    // check if capability is right for this action
    if (Checks.userCan('create_kontentblocks')) {
    } else {
Severity: Minor
Found in js/src/shared/ModuleBrowser/ModuleBrowserController.js - About 1 hr to fix

    Expected '===' and instead saw '=='.
    Open

        if (curr == 'list') {

    Require === and !== (eqeqeq)

    It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=.

    The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm. For instance, the following statements are all considered true:

    • [] == false
    • [] == ![]
    • 3 == "03"

    If one of those occurs in an innocent-looking statement such as a == b the actual problem is very difficult to spot.

    Rule Details

    This rule is aimed at eliminating the type-unsafe equality operators.

    Examples of incorrect code for this rule:

    /*eslint eqeqeq: "error"*/
    
    if (x == 42) { }
    
    if ("" == text) { }
    
    if (obj.getStuff() != undefined) { }

    The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

    Options

    always

    The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

    Examples of incorrect code for the "always" option:

    /*eslint eqeqeq: ["error", "always"]*/
    
    a == b
    foo == true
    bananas != 1
    value == undefined
    typeof foo == 'undefined'
    'hello' != 'world'
    0 == 0
    true == true
    foo == null

    Examples of correct code for the "always" option:

    /*eslint eqeqeq: ["error", "always"]*/
    
    a === b
    foo === true
    bananas !== 1
    value === undefined
    typeof foo === 'undefined'
    'hello' !== 'world'
    0 === 0
    true === true
    foo === null

    This rule optionally takes a second argument, which should be an object with the following supported properties:

    • "null": Customize how this rule treats null literals. Possible values:
      • always (default) - Always use === or !==.
      • never - Never use === or !== with null.
      • ignore - Do not apply this rule to null.

    smart

    The "smart" option enforces the use of === and !== except for these cases:

    • Comparing two literal values
    • Evaluating the value of typeof
    • Comparing against null

    Examples of incorrect code for the "smart" option:

    /*eslint eqeqeq: ["error", "smart"]*/
    
    // comparing two variables requires ===
    a == b
    
    // only one side is a literal
    foo == true
    bananas != 1
    
    // comparing to undefined requires ===
    value == undefined

    Examples of correct code for the "smart" option:

    /*eslint eqeqeq: ["error", "smart"]*/
    
    typeof foo == 'undefined'
    'hello' != 'world'
    0 == 0
    true == true
    foo == null

    allow-null

    Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null literal.

    ["error", "always", {"null": "ignore"}]

    When Not To Use It

    If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

    Empty block statement.
    Open

        if (Checks.userCan('create_kontentblocks')) {

    disallow empty block statements (no-empty)

    Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

    Rule Details

    This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

    Examples of incorrect code for this rule:

    /*eslint no-empty: "error"*/
    
    if (foo) {
    }
    
    while (foo) {
    }
    
    switch(foo) {
    }
    
    try {
        doSomething();
    } catch(ex) {
    
    } finally {
    
    }

    Examples of correct code for this rule:

    /*eslint no-empty: "error"*/
    
    if (foo) {
        // empty
    }
    
    while (foo) {
        /* empty */
    }
    
    try {
        doSomething();
    } catch (ex) {
        // continue regardless of error
    }
    
    try {
        doSomething();
    } finally {
        /* continue regardless of error */
    }

    Options

    This rule has an object option for exceptions:

    • "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

    allowEmptyCatch

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

    /* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
    try {
        doSomething();
    } catch (ex) {}
    
    try {
        doSomething();
    }
    catch (ex) {}
    finally {
        /* continue regardless of error */
    }

    When Not To Use It

    If you intentionally use empty block statements then you can disable this rule.

    Related Rules

    TODO found
    Open

      // TODO Re-initialize ui components

    TODO found
    Open

        // @TODO a module class which was assigned to an area is not necessarily present

    TODO found
    Open

      // TODO clean up and remove all references & bindings

    There are no issues that match your filters.

    Category
    Status