public/assets/js/core/chosen/chosen.jquery.js

Summary

Maintainability
F
1 mo
Test Coverage

File chosen.jquery.js has 1109 lines of code (exceeds 250 allowed). Consider refactoring.
Open

/*!
Chosen, a Select Box Enhancer for jQuery and Prototype
by Patrick Filler for Harvest, http://getharvest.com

Version 1.1.0
Severity: Major
Found in public/assets/js/core/chosen/chosen.jquery.js - About 2 days to fix

    Function has too many statements (46). Maximum allowed is 30.
    Open

      Chosen = (function(_super) {

    enforce a maximum number of statements allowed in function blocks (max-statements)

    The max-statements rule allows you to specify the maximum number of statements allowed in a function.

    function foo() {
      var bar = 1; // one statement
      var baz = 2; // two statements
      var qux = 3; // three statements
    }

    Rule Details

    This rule enforces a maximum number of statements allowed in function blocks.

    Options

    This rule has a number or object option:

    • "max" (default 10) enforces a maximum number of statements allows in function blocks

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

    This rule has an object option:

    • "ignoreTopLevelFunctions": true ignores top-level functions

    max

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

    /*eslint max-statements: ["error", 10]*/
    /*eslint-env es6*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
    
      var foo11 = 11; // Too many.
    }
    
    let foo = () => {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
    
      var foo11 = 11; // Too many.
    };

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

    /*eslint max-statements: ["error", 10]*/
    /*eslint-env es6*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      return function () {
    
        // The number of statements in the inner function does not count toward the
        // statement maximum.
    
        return 42;
      };
    }
    
    let foo = () => {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      return function () {
    
        // The number of statements in the inner function does not count toward the
        // statement maximum.
    
        return 42;
      };
    }

    ignoreTopLevelFunctions

    Examples of additional correct code for this rule with the { "max": 10 }, { "ignoreTopLevelFunctions": true } options:

    /*eslint max-statements: ["error", 10, { "ignoreTopLevelFunctions": true }]*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      var foo11 = 11;
    }

    Related Rules

    • [complexity](complexity.md)
    • [max-depth](max-depth.md)
    • [max-len](max-len.md)
    • [max-nested-callbacks](max-nested-callbacks.md)
    • [max-params](max-params.md) Source: http://eslint.org/docs/rules/

    Function has too many statements (41). Maximum allowed is 30.
    Open

        AbstractChosen.prototype.winnow_results = function() {

    enforce a maximum number of statements allowed in function blocks (max-statements)

    The max-statements rule allows you to specify the maximum number of statements allowed in a function.

    function foo() {
      var bar = 1; // one statement
      var baz = 2; // two statements
      var qux = 3; // three statements
    }

    Rule Details

    This rule enforces a maximum number of statements allowed in function blocks.

    Options

    This rule has a number or object option:

    • "max" (default 10) enforces a maximum number of statements allows in function blocks

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

    This rule has an object option:

    • "ignoreTopLevelFunctions": true ignores top-level functions

    max

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

    /*eslint max-statements: ["error", 10]*/
    /*eslint-env es6*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
    
      var foo11 = 11; // Too many.
    }
    
    let foo = () => {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
    
      var foo11 = 11; // Too many.
    };

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

    /*eslint max-statements: ["error", 10]*/
    /*eslint-env es6*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      return function () {
    
        // The number of statements in the inner function does not count toward the
        // statement maximum.
    
        return 42;
      };
    }
    
    let foo = () => {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      return function () {
    
        // The number of statements in the inner function does not count toward the
        // statement maximum.
    
        return 42;
      };
    }

    ignoreTopLevelFunctions

    Examples of additional correct code for this rule with the { "max": 10 }, { "ignoreTopLevelFunctions": true } options:

    /*eslint max-statements: ["error", 10, { "ignoreTopLevelFunctions": true }]*/
    
    function foo() {
      var foo1 = 1;
      var foo2 = 2;
      var foo3 = 3;
      var foo4 = 4;
      var foo5 = 5;
      var foo6 = 6;
      var foo7 = 7;
      var foo8 = 8;
      var foo9 = 9;
      var foo10 = 10;
      var foo11 = 11;
    }

    Related Rules

    • [complexity](complexity.md)
    • [max-depth](max-depth.md)
    • [max-len](max-len.md)
    • [max-nested-callbacks](max-nested-callbacks.md)
    • [max-params](max-params.md) Source: http://eslint.org/docs/rules/

    Function register_observers has 73 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

        Chosen.prototype.register_observers = function() {
          var _this = this;
          this.container.bind('mousedown.chosen', function(evt) {
            _this.container_mousedown(evt);
          });
    Severity: Major
    Found in public/assets/js/core/chosen/chosen.jquery.js - About 2 hrs to fix

      Function has a complexity of 15.
      Open

          AbstractChosen.prototype.keyup_checker = function(evt) {

      Limit Cyclomatic Complexity (complexity)

      Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

      function a(x) {
          if (true) {
              return x; // 1st path
          } else if (false) {
              return x+1; // 2nd path
          } else {
              return 4; // 3rd path
          }
      }

      Rule Details

      This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

      Examples of incorrect code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else if (false) {
              return x+1;
          } else {
              return 4; // 3rd path
          }
      }

      Examples of correct code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else {
              return 4;
          }
      }

      Options

      Optionally, you may specify a max object property:

      "complexity": ["error", 2]

      is equivalent to

      "complexity": ["error", { "max": 2 }]

      Deprecated: the object property maximum is deprecated. Please use the property max instead.

      When Not To Use It

      If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

      Further Reading

      Related Rules

      • [max-depth](max-depth.md)
      • [max-len](max-len.md)
      • [max-nested-callbacks](max-nested-callbacks.md)
      • [max-params](max-params.md)
      • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

      Function has a complexity of 15.
      Open

          AbstractChosen.prototype.winnow_results = function() {

      Limit Cyclomatic Complexity (complexity)

      Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

      function a(x) {
          if (true) {
              return x; // 1st path
          } else if (false) {
              return x+1; // 2nd path
          } else {
              return 4; // 3rd path
          }
      }

      Rule Details

      This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

      Examples of incorrect code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else if (false) {
              return x+1;
          } else {
              return 4; // 3rd path
          }
      }

      Examples of correct code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else {
              return 4;
          }
      }

      Options

      Optionally, you may specify a max object property:

      "complexity": ["error", 2]

      is equivalent to

      "complexity": ["error", { "max": 2 }]

      Deprecated: the object property maximum is deprecated. Please use the property max instead.

      When Not To Use It

      If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

      Further Reading

      Related Rules

      • [max-depth](max-depth.md)
      • [max-len](max-len.md)
      • [max-nested-callbacks](max-nested-callbacks.md)
      • [max-params](max-params.md)
      • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

      Function has a complexity of 12.
      Open

          AbstractChosen.prototype.set_default_values = function() {

      Limit Cyclomatic Complexity (complexity)

      Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

      function a(x) {
          if (true) {
              return x; // 1st path
          } else if (false) {
              return x+1; // 2nd path
          } else {
              return 4; // 3rd path
          }
      }

      Rule Details

      This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

      Examples of incorrect code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else if (false) {
              return x+1;
          } else {
              return 4; // 3rd path
          }
      }

      Examples of correct code for a maximum of 2:

      /*eslint complexity: ["error", 2]*/
      
      function a(x) {
          if (true) {
              return x;
          } else {
              return 4;
          }
      }

      Options

      Optionally, you may specify a max object property:

      "complexity": ["error", 2]

      is equivalent to

      "complexity": ["error", { "max": 2 }]

      Deprecated: the object property maximum is deprecated. Please use the property max instead.

      When Not To Use It

      If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

      Further Reading

      Related Rules

      • [max-depth](max-depth.md)
      • [max-len](max-len.md)
      • [max-nested-callbacks](max-nested-callbacks.md)
      • [max-params](max-params.md)
      • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

      Function winnow_results has 54 lines of code (exceeds 25 allowed). Consider refactoring.
      Open

          AbstractChosen.prototype.winnow_results = function() {
            var escapedSearchText, option, regex, regexAnchor, results, results_group, searchText, startpos, text, zregex, _i, _len, _ref;
            this.no_results_clear();
            results = 0;
            searchText = this.get_search_text();
      Severity: Major
      Found in public/assets/js/core/chosen/chosen.jquery.js - About 2 hrs to fix

        Function has a complexity of 9.
        Open

            Chosen.prototype.result_select = function(evt) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 9.
        Open

            Chosen.prototype.keydown_checker = function(evt) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 9.
        Open

            AbstractChosen.prototype.set_default_text = function() {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 8.
        Open

            Chosen.prototype.container_mousedown = function(evt) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 8.
        Open

            AbstractChosen.prototype.result_add_option = function(option) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has too many statements (31). Maximum allowed is 30.
        Open

          AbstractChosen = (function() {

        enforce a maximum number of statements allowed in function blocks (max-statements)

        The max-statements rule allows you to specify the maximum number of statements allowed in a function.

        function foo() {
          var bar = 1; // one statement
          var baz = 2; // two statements
          var qux = 3; // three statements
        }

        Rule Details

        This rule enforces a maximum number of statements allowed in function blocks.

        Options

        This rule has a number or object option:

        • "max" (default 10) enforces a maximum number of statements allows in function blocks

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

        This rule has an object option:

        • "ignoreTopLevelFunctions": true ignores top-level functions

        max

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

        /*eslint max-statements: ["error", 10]*/
        /*eslint-env es6*/
        
        function foo() {
          var foo1 = 1;
          var foo2 = 2;
          var foo3 = 3;
          var foo4 = 4;
          var foo5 = 5;
          var foo6 = 6;
          var foo7 = 7;
          var foo8 = 8;
          var foo9 = 9;
          var foo10 = 10;
        
          var foo11 = 11; // Too many.
        }
        
        let foo = () => {
          var foo1 = 1;
          var foo2 = 2;
          var foo3 = 3;
          var foo4 = 4;
          var foo5 = 5;
          var foo6 = 6;
          var foo7 = 7;
          var foo8 = 8;
          var foo9 = 9;
          var foo10 = 10;
        
          var foo11 = 11; // Too many.
        };

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

        /*eslint max-statements: ["error", 10]*/
        /*eslint-env es6*/
        
        function foo() {
          var foo1 = 1;
          var foo2 = 2;
          var foo3 = 3;
          var foo4 = 4;
          var foo5 = 5;
          var foo6 = 6;
          var foo7 = 7;
          var foo8 = 8;
          var foo9 = 9;
          var foo10 = 10;
          return function () {
        
            // The number of statements in the inner function does not count toward the
            // statement maximum.
        
            return 42;
          };
        }
        
        let foo = () => {
          var foo1 = 1;
          var foo2 = 2;
          var foo3 = 3;
          var foo4 = 4;
          var foo5 = 5;
          var foo6 = 6;
          var foo7 = 7;
          var foo8 = 8;
          var foo9 = 9;
          var foo10 = 10;
          return function () {
        
            // The number of statements in the inner function does not count toward the
            // statement maximum.
        
            return 42;
          };
        }

        ignoreTopLevelFunctions

        Examples of additional correct code for this rule with the { "max": 10 }, { "ignoreTopLevelFunctions": true } options:

        /*eslint max-statements: ["error", 10, { "ignoreTopLevelFunctions": true }]*/
        
        function foo() {
          var foo1 = 1;
          var foo2 = 2;
          var foo3 = 3;
          var foo4 = 4;
          var foo5 = 5;
          var foo6 = 6;
          var foo7 = 7;
          var foo8 = 8;
          var foo9 = 9;
          var foo10 = 10;
          var foo11 = 11;
        }

        Related Rules

        • [complexity](complexity.md)
        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 7.
        Open

            AbstractChosen.prototype.results_option_build = function(options) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 7.
        Open

            AbstractChosen.prototype.search_string_match = function(search_string, regex) {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function has a complexity of 7.
        Open

            Chosen.prototype.set_up_html = function() {

        Limit Cyclomatic Complexity (complexity)

        Cyclomatic complexity measures the number of linearly independent paths through a program's source code. This rule allows setting a cyclomatic complexity threshold.

        function a(x) {
            if (true) {
                return x; // 1st path
            } else if (false) {
                return x+1; // 2nd path
            } else {
                return 4; // 3rd path
            }
        }

        Rule Details

        This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will warn when the cyclomatic complexity crosses the configured threshold (default is 20).

        Examples of incorrect code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else if (false) {
                return x+1;
            } else {
                return 4; // 3rd path
            }
        }

        Examples of correct code for a maximum of 2:

        /*eslint complexity: ["error", 2]*/
        
        function a(x) {
            if (true) {
                return x;
            } else {
                return 4;
            }
        }

        Options

        Optionally, you may specify a max object property:

        "complexity": ["error", 2]

        is equivalent to

        "complexity": ["error", { "max": 2 }]

        Deprecated: the object property maximum is deprecated. Please use the property max instead.

        When Not To Use It

        If you can't determine an appropriate complexity limit for your code, then it's best to disable this rule.

        Further Reading

        Related Rules

        • [max-depth](max-depth.md)
        • [max-len](max-len.md)
        • [max-nested-callbacks](max-nested-callbacks.md)
        • [max-params](max-params.md)
        • [max-statements](max-statements.md) Source: http://eslint.org/docs/rules/

        Function set_up_html has 42 lines of code (exceeds 25 allowed). Consider refactoring.
        Open

            Chosen.prototype.set_up_html = function() {
              var container_classes, container_props;
              container_classes = ["chosen-container"];
              container_classes.push("chosen-container-" + (this.is_multiple ? "multi" : "single"));
              if (this.inherit_select_classes && this.form_field.className) {
        Severity: Minor
        Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

          Function result_select has 36 lines of code (exceeds 25 allowed). Consider refactoring.
          Open

              Chosen.prototype.result_select = function(evt) {
                var high, item;
                if (this.result_highlight) {
                  high = this.result_highlight;
                  this.result_clear_highlight();
          Severity: Minor
          Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

            Function keyup_checker has 33 lines of code (exceeds 25 allowed). Consider refactoring.
            Open

                AbstractChosen.prototype.keyup_checker = function(evt) {
                  var stroke, _ref;
                  stroke = (_ref = evt.which) != null ? _ref : evt.keyCode;
                  this.search_field_scale();
                  switch (stroke) {
            Severity: Minor
            Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

              Function result_add_option has 29 lines of code (exceeds 25 allowed). Consider refactoring.
              Open

                  AbstractChosen.prototype.result_add_option = function(option) {
                    var classes, option_el;
                    if (!option.search_match) {
                      return '';
                    }
              Severity: Minor
              Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

                Function keydown_checker has 28 lines of code (exceeds 25 allowed). Consider refactoring.
                Open

                    Chosen.prototype.keydown_checker = function(evt) {
                      var stroke, _ref1;
                      stroke = (_ref1 = evt.which) != null ? _ref1 : evt.keyCode;
                      this.search_field_scale();
                      if (stroke !== 8 && this.pending_backstroke) {
                Severity: Minor
                Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

                  Function add_option has 26 lines of code (exceeds 25 allowed). Consider refactoring.
                  Open

                      SelectParser.prototype.add_option = function(option, group_position, group_disabled) {
                        if (option.nodeName.toUpperCase() === "OPTION") {
                          if (option.text !== "") {
                            if (group_position != null) {
                              this.parsed[group_position].children += 1;
                  Severity: Minor
                  Found in public/assets/js/core/chosen/chosen.jquery.js - About 1 hr to fix

                    Avoid deeply nested control flow statements.
                    Open

                                  if (results_group != null) {
                                    results_group.group_match = true;
                                  }
                    Severity: Major
                    Found in public/assets/js/core/chosen/chosen.jquery.js - About 45 mins to fix

                      Avoid deeply nested control flow statements.
                      Open

                                  } else if ((option.group_array_index != null) && this.results_data[option.group_array_index].search_match) {
                                    option.search_match = true;
                                  }
                      Severity: Major
                      Found in public/assets/js/core/chosen/chosen.jquery.js - About 45 mins to fix

                        Avoid deeply nested control flow statements.
                        Open

                                      if (searchText.length) {
                                        startpos = option.search_text.search(zregex);
                                        text = option.search_text.substr(0, startpos + searchText.length) + '</em>' + option.search_text.substr(startpos + searchText.length);
                                        option.search_text = text.substr(0, startpos) + '<em>' + text.substr(startpos);
                                      }
                        Severity: Major
                        Found in public/assets/js/core/chosen/chosen.jquery.js - About 45 mins to fix

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

                                this.allow_single_deselect = (this.options.allow_single_deselect != null) && (this.form_field.options[0] != null) && this.form_field.options[0].text === "" ? this.options.allow_single_deselect : false;

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.enable_split_word_search = this.options.enable_split_word_search != null ? this.options.enable_split_word_search : true;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                this.enable_split_word_search = this.options.enable_split_word_search != null ? this.options.enable_split_word_search : true;

                          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/

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

                                      } else if ((option.group_array_index != null) && this.results_data[option.group_array_index].search_match) {

                          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/

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

                                if (delta != null) {

                          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/

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

                                if (text == null) {

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.options = options != null ? options : {};

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                if (option.group_array_index != null) {

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                      } else if ((option.group_array_index != null) && this.results_data[option.group_array_index].search_match) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Return statement should not contain assignment.
                          Open

                                  return this.active_field = true;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

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

                                return this.display_disabled_options = this.options.display_disabled_options != null ? this.options.display_disabled_options : true;

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (option.group_array_index != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                    if ((option.group_array_index != null) && this.results_data[option.group_array_index]) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                stroke = (_ref = evt.which) != null ? _ref : evt.keyCode;

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.mouse_on_container = false;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

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

                                  if (options != null ? options.first : void 0) {

                          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/

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

                                  if (!((evt != null) && ($(evt.target)).hasClass("search-choice-close"))) {

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                stroke = (_ref1 = evt.which) != null ? _ref1 : evt.keyCode;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                if ((text == null) || text === false) {

                          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/

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

                                this.allow_single_deselect = (this.options.allow_single_deselect != null) && (this.form_field.options[0] != null) && this.form_field.options[0].text === "" ? this.options.allow_single_deselect : false;

                          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/

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

                                this.display_selected_options = this.options.display_selected_options != null ? this.options.display_selected_options : true;

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.display_disabled_options = this.options.display_disabled_options != null ? this.options.display_disabled_options : true;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

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

                                    if (group_position != null) {

                          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/

                          Return statement should not contain assignment.
                          Open

                                  return this.options_index += 1;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if ((text == null) || text === false) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                if (this.selected_option_count != null) {

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.allow_single_deselect = (this.options.allow_single_deselect != null) && (this.form_field.options[0] != null) && this.form_field.options[0].text === "" ? this.options.allow_single_deselect : false;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.display_selected_options = this.options.display_selected_options != null ? this.options.display_selected_options : true;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (this.options.width != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (delta != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.group_search = this.options.group_search != null ? this.options.group_search : true;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                        if (results_group != null) {

                          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/

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

                                if (this.options.width != null) {

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.results_none_found = this.form_field.getAttribute("data-no_results_text") || this.options.no_results_text || AbstractChosen.default_no_result_text;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                stroke = (_ref = evt.which) != null ? _ref : evt.keyCode;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                  if (!((evt != null) && ($(evt.target)).hasClass("search-choice-close"))) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                if (do_high != null) {

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.pending_backstroke = null;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.single_backstroke_delete = this.options.single_backstroke_delete != null ? this.options.single_backstroke_delete : true;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Return statement should not contain assignment.
                          Open

                                return this.results_showing = false;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (text == null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                this.options = options != null ? options : {};

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                        if (results_group != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (do_high != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                stroke = (_ref1 = evt.which) != null ? _ref1 : evt.keyCode;

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                    if (group_position != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                this.single_backstroke_delete = this.options.single_backstroke_delete != null ? this.options.single_backstroke_delete : true;

                          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/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                return this.display_disabled_options = this.options.display_disabled_options != null ? this.options.display_disabled_options : true;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                this.allow_single_deselect = (this.options.allow_single_deselect != null) && (this.form_field.options[0] != null) && this.form_field.options[0].text === "" ? this.options.allow_single_deselect : false;

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Use ‘===’ to compare with ‘null’.
                          Open

                                if (this.selected_option_count != null) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

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

                                    if ((option.group_array_index != null) && this.results_data[option.group_array_index]) {

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.is_rtl = this.form_field_jq.hasClass("chosen-rtl");

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

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

                                this.group_search = this.options.group_search != null ? this.options.group_search : true;

                          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/

                          Return statement should not contain assignment.
                          Open

                                return this.mouse_on_container = true;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Use ‘===’ to compare with ‘null’.
                          Open

                                  if (options != null ? options.first : void 0) {

                          Disallow Null Comparisons (no-eq-null)

                          Comparing to null without a type-checking operator (== or !=), can have unintended results as the comparison will evaluate to true when comparing to not just a null, but also an undefined value.

                          if (foo == null) {
                            bar();
                          }

                          Rule Details

                          The no-eq-null rule aims reduce potential bug and unwanted behavior by ensuring that comparisons to null only match null, and not also undefined. As such it will flag comparisons to null when using == and !=.

                          Examples of incorrect code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo == null) {
                            bar();
                          }
                          
                          while (qux != null) {
                            baz();
                          }

                          Examples of correct code for this rule:

                          /*eslint no-eq-null: "error"*/
                          
                          if (foo === null) {
                            bar();
                          }
                          
                          while (qux !== null) {
                            baz();
                          }

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

                          Return statement should not contain assignment.
                          Open

                                return this.parsing = false;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Return statement should not contain assignment.
                          Open

                                return this.result_highlight = null;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Return statement should not contain assignment.
                          Open

                                  return this.search_field[0].tabIndex = ti;

                          Disallow Assignment in return Statement (no-return-assign)

                          One of the interesting, and sometimes confusing, aspects of JavaScript is that assignment can happen at almost any point. Because of this, an errant equals sign can end up causing assignment when the true intent was to do a comparison. This is especially true when using a return statement. For example:

                          function doSomething() {
                              return foo = bar + 2;
                          }

                          It is difficult to tell the intent of the return statement here. It's possible that the function is meant to return the result of bar + 2, but then why is it assigning to foo? It's also possible that the intent was to use a comparison operator such as == and that this code is an error.

                          Because of this ambiguity, it's considered a best practice to not use assignment in return statements.

                          Rule Details

                          This rule aims to eliminate assignments from return statements. As such, it will warn whenever an assignment is found as part of return.

                          Options

                          The rule takes one option, a string, which must contain one of the following values:

                          • except-parens (default): Disallow assignments unless they are enclosed in parentheses.
                          • always: Disallow all assignments.

                          except-parens

                          This is the default option. It disallows assignments unless they are enclosed in parentheses.

                          Examples of incorrect code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }

                          Examples of correct code for the default "except-parens" option:

                          /*eslint no-return-assign: "error"*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          always

                          This option disallows all assignments in return statements. All assignments are treated as problems.

                          Examples of incorrect code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo = bar + 2;
                          }
                          
                          function doSomething() {
                              return foo += 2;
                          }
                          
                          function doSomething() {
                              return (foo = bar + 2);
                          }

                          Examples of correct code for the "always" option:

                          /*eslint no-return-assign: ["error", "always"]*/
                          
                          function doSomething() {
                              return foo == bar + 2;
                          }
                          
                          function doSomething() {
                              return foo === bar + 2;
                          }

                          When Not To Use It

                          If you want to allow the use of assignment operators in a return statement, then you can safely disable this rule. Source: http://eslint.org/docs/rules/

                          Expected 'undefined' and instead saw 'void'.
                          Open

                                    _results.push(void 0);

                          Disallow use of the void operator. (no-void)

                          The void operator takes an operand and returns undefined: void expression will evaluate expression and return undefined. It can be used to ignore any side effects expression may produce:

                          The common case of using void operator is to get a "pure" undefined value as prior to ES5 the undefined variable was mutable:

                          // will always return undefined
                          (function(){
                              return void 0;
                          })();
                          
                          // will return 1 in ES3 and undefined in ES5+
                          (function(){
                              undefined = 1;
                              return undefined;
                          })();
                          
                          // will throw TypeError in ES5+
                          (function(){
                              'use strict';
                              undefined = 1;
                          })();

                          Another common case is to minify code as void 0 is shorter than undefined:

                          foo = void 0;
                          foo = undefined;

                          When used with IIFE (immediately-invoked function expression), void can be used to force the function keyword to be treated as an expression instead of a declaration:

                          var foo = 1;
                          void function(){ foo = 1; }() // will assign foo a value of 1
                          +function(){ foo = 1; }() // same as above
                          function(){ foo = 1; }() // will throw SyntaxError

                          Some code styles prohibit void operator, marking it as non-obvious and hard to read.

                          Rule Details

                          This rule aims to eliminate use of void operator.

                          Examples of incorrect code for this rule:

                          /*eslint no-void: "error"*/
                          
                          void foo
                          
                          var foo = void bar();

                          When Not To Use It

                          If you intentionally use the void operator then you can disable this rule.

                          Further Reading

                          Related Rules

                          Expected 'undefined' and instead saw 'void'.
                          Open

                                  if (options != null ? options.first : void 0) {

                          Disallow use of the void operator. (no-void)

                          The void operator takes an operand and returns undefined: void expression will evaluate expression and return undefined. It can be used to ignore any side effects expression may produce:

                          The common case of using void operator is to get a "pure" undefined value as prior to ES5 the undefined variable was mutable:

                          // will always return undefined
                          (function(){
                              return void 0;
                          })();
                          
                          // will return 1 in ES3 and undefined in ES5+
                          (function(){
                              undefined = 1;
                              return undefined;
                          })();
                          
                          // will throw TypeError in ES5+
                          (function(){
                              'use strict';
                              undefined = 1;
                          })();

                          Another common case is to minify code as void 0 is shorter than undefined:

                          foo = void 0;
                          foo = undefined;

                          When used with IIFE (immediately-invoked function expression), void can be used to force the function keyword to be treated as an expression instead of a declaration:

                          var foo = 1;
                          void function(){ foo = 1; }() // will assign foo a value of 1
                          +function(){ foo = 1; }() // same as above
                          function(){ foo = 1; }() // will throw SyntaxError

                          Some code styles prohibit void operator, marking it as non-obvious and hard to read.

                          Rule Details

                          This rule aims to eliminate use of void operator.

                          Examples of incorrect code for this rule:

                          /*eslint no-void: "error"*/
                          
                          void foo
                          
                          var foo = void bar();

                          When Not To Use It

                          If you intentionally use the void operator then you can disable this rule.

                          Further Reading

                          Related Rules

                          Move the invocation into the parens that contain the function.
                          Open

                            SelectParser = (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/

                          Move the invocation into the parens that contain the function.
                          Open

                            AbstractChosen = (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/

                          Move the invocation into the parens that contain the function.
                          Open

                            Chosen = (function(_super) {

                          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/

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                            AbstractChosen = (function() {
                              function AbstractChosen(form_field, options) {
                                this.form_field = form_field;
                                this.options = options != null ? options : {};
                                if (!AbstractChosen.browser_is_supported()) {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 3 wks to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 116..521

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 4139.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                            SelectParser = (function() {
                              function SelectParser() {
                                this.options_index = 0;
                                this.parsed = [];
                              }
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 4 days to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 18..103

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 729.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                              Chosen.prototype.single_set_selected_text = function(text) {
                                if (text == null) {
                                  text = this.default_text;
                                }
                                if (text === this.default_text) {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 4 hrs to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 1024..1035

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 125.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 3 locations. Consider refactoring.
                          Open

                              __extends = function(child, parent) { for (var key in parent) { if (__hasProp.call(parent, key)) child[key] = parent[key]; } function ctor() { this.constructor = child; } ctor.prototype = parent.prototype; child.prototype = new ctor(); child.__super__ = parent.prototype; return child; };
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 2 other locations - About 4 hrs to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 16..16
                          public/assets/js/core/jqtree/tree.jquery.js on lines 23..23

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 119.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                            SelectParser.select_to_array = function(select) {
                              var child, parser, _i, _len, _ref;
                              parser = new SelectParser();
                              _ref = select.childNodes;
                              for (_i = 0, _len = _ref.length; _i < _len; _i++) {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 4 hrs to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 105..114

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 116.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                              Chosen.prototype.results_hide = function() {
                                if (this.results_showing) {
                                  this.result_clear_highlight();
                                  this.container.removeClass("chosen-with-drop");
                                  this.form_field_jq.trigger("chosen:hiding_dropdown", {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 2 hrs to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 849..858

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 89.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                  for (_i = 0, _len = styles.length; _i < _len; _i++) {
                                    style = styles[_i];
                                    style_block += style + ":" + this.search_field.css(style) + ";";
                                  }
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 1207..1210

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 74.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                  if (prev_sibs.length) {
                                    return this.result_do_highlight(prev_sibs.first());
                                  } else {
                                    if (this.choices_count() > 0) {
                                      this.results_hide();
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 1130..1137

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 71.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                } else {
                                  this.search_container = this.container.find('div.chosen-search').first();
                                  this.selected_item = this.container.find('.chosen-single').first();
                                }
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 587..590

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 63.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                if (this.is_multiple) {
                                  this.search_choices = this.container.find('ul.chosen-choices').first();
                                  this.search_container = this.container.find('li.search-field').first();
                                } else {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 590..593

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 63.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                if (this.form_field_label.length > 0) {
                                  return this.form_field_label.bind('click.chosen', function(evt) {
                                    if (_this.is_multiple) {
                                      return _this.container_mousedown(evt);
                                    } else {
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 875..883

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 62.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                              Chosen.prototype.container_mouseup = function(evt) {
                                if (evt.target.nodeName === "ABBR" && !this.is_disabled) {
                                  return this.results_reset(evt);
                                }
                              };
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 730..734

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 61.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                                target = $(evt.target).hasClass("active-result") ? $(evt.target) : $(evt.target).parents(".active-result").first();
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 911..911

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 60.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                                target = $(evt.target).hasClass("active-result") ? $(evt.target) : $(evt.target).parents(".active-result").first();
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 901..901

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 60.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                              Chosen.prototype.blur_test = function(evt) {
                                if (!this.active_field && this.container.hasClass("chosen-container-active")) {
                                  return this.close_field();
                                }
                              };
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 748..752

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 60.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 4 locations. Consider refactoring.
                          Open

                              Chosen.prototype.result_clear_highlight = function() {
                                if (this.result_highlight) {
                                  this.result_highlight.removeClass("highlighted");
                                }
                                return this.result_highlight = null;
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 3 other locations - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 1141..1146
                          public/assets/js/core/chosen/chosen.proto.js on lines 821..826
                          public/assets/js/core/chosen/chosen.proto.js on lines 1162..1167

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 57.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 4 locations. Consider refactoring.
                          Open

                              Chosen.prototype.clear_backstroke = function() {
                                if (this.pending_backstroke) {
                                  this.pending_backstroke.removeClass("search-choice-focus");
                                }
                                return this.pending_backstroke = null;
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 3 other locations - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 824..829
                          public/assets/js/core/chosen/chosen.proto.js on lines 821..826
                          public/assets/js/core/chosen/chosen.proto.js on lines 1162..1167

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 57.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 4 locations. Consider refactoring.
                          Open

                                  if (this.is_multiple && this.max_selected_options <= this.choices_count()) {
                                    this.form_field_jq.trigger("chosen:maxselected", {
                                      chosen: this
                                    });
                                    return false;
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 3 other locations - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 832..837
                          public/assets/js/core/chosen/chosen.proto.js on lines 829..834
                          public/assets/js/core/chosen/chosen.proto.js on lines 991..996

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 55.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 4 locations. Consider refactoring.
                          Open

                                if (this.is_multiple && this.max_selected_options <= this.choices_count()) {
                                  this.form_field_jq.trigger("chosen:maxselected", {
                                    chosen: this
                                  });
                                  return false;
                          Severity: Major
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 3 other locations - About 1 hr to fix
                          public/assets/js/core/chosen/chosen.jquery.js on lines 985..990
                          public/assets/js/core/chosen/chosen.proto.js on lines 829..834
                          public/assets/js/core/chosen/chosen.proto.js on lines 991..996

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 55.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Similar blocks of code found in 2 locations. Consider refactoring.
                          Open

                                container_props = {
                                  'class': container_classes.join(' '),
                                  'style': "width: " + (this.container_width()) + ";",
                                  'title': this.form_field.title
                                };
                          Severity: Minor
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 55 mins to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 553..557

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 54.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                                if (this.form_field.id.length) {
                                  container_props.id = this.form_field.id.replace(/[^\w]/g, '_') + "_chosen";
                                }
                          Severity: Minor
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 50 mins to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 558..560

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 51.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          Identical blocks of code found in 2 locations. Consider refactoring.
                          Open

                                  case 9:
                                    if (this.results_showing && !this.is_multiple) {
                                      this.result_select(evt);
                                    }
                                    this.mouse_on_container = false;
                          Severity: Minor
                          Found in public/assets/js/core/chosen/chosen.jquery.js and 1 other location - About 40 mins to fix
                          public/assets/js/core/chosen/chosen.proto.js on lines 1180..1185

                          Duplicated Code

                          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

                          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

                          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

                          Tuning

                          This issue has a mass of 48.

                          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

                          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

                          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

                          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

                          Refactorings

                          Further Reading

                          There are no issues that match your filters.

                          Category
                          Status