IdentityPython/pyFF

View on GitHub
src/pyff/site/static/js/ds-client.js

Summary

Maintainability
C
1 day
Test Coverage

Function each has 38 lines of code (exceeds 25 allowed). Consider refactoring.
Open

    DiscoveryService.prototype.each = function(callback) {
        var obj = this;
        var storage = this.get_storage();
        return storage.onConnect().then(function () {
            console.log(storage_key);
Severity: Minor
Found in src/pyff/site/static/js/ds-client.js - About 1 hr to fix

    Function choices has 31 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

        DiscoveryService.prototype.choices = function() {
            var obj = this;
            var storage = this.get_storage();
            return storage.onConnect().then(function () {
                console.log(storage_key);
    Severity: Minor
    Found in src/pyff/site/static/js/ds-client.js - About 1 hr to fix

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

          DiscoveryService.prototype.add = function (id) {
              var storage = this.get_storage();
              var obj = this;
              return storage.onConnect().then(function () {
                  return storage.get(storage_key);
      Severity: Minor
      Found in src/pyff/site/static/js/ds-client.js - About 1 hr to fix

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

                    if (DiscoveryService._incr_use_count(id,lst) == -1) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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 (list[i].entity.entity_id == entity_id || list[i].entity.entityID == entity_id) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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/

        Shadowing of global property 'undefined'.
        Open

            (function(window, undefined) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        Disallow Shadowing of Restricted Names (no-shadow-restricted-names)

        ES5 §15.1.1 Value Properties of the Global Object (NaN, Infinity, undefined) as well as strict mode restricted identifiers eval and arguments are considered to be restricted names in JavaScript. Defining them to mean something else can have unintended consequences and confuse others reading the code. For example, there's nothing prevent you from writing:

        var undefined = "foo";

        Then any code used within the same scope would not get the global undefined, but rather the local version with a very different meaning.

        Rule Details

        Examples of incorrect code for this rule:

        /*eslint no-shadow-restricted-names: "error"*/
        
        function NaN(){}
        
        !function(Infinity){};
        
        var undefined;
        
        try {} catch(eval){}

        Examples of correct code for this rule:

        /*eslint no-shadow-restricted-names: "error"*/
        
        var Object;
        
        function f(a, b){}

        Further Reading

        Related Rules

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

                    if (list[i].entity.entity_id == entity_id || list[i].entity.entityID == entity_id) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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

                        return item.entity.entity_id != id && item.entity.entityID != id;
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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

                        return item.entity.entity_id != id && item.entity.entityID != id;
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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 (last_refresh == -1 || last_refresh + cache_time < DiscoveryService._now()) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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/

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

            DiscoveryService._querystring = (function(paramsArray) {
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js by eslint

        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/

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

                    lst.sort(function (a, b) { // decending order - most commonly used stuff on top
                        if (a.use_count < b.use_count) {
                            return 1;
                        }
                        if (a.use_count > b.use_count) {
        Severity: Major
        Found in src/pyff/site/static/js/ds-client.js and 1 other location - About 1 hr to fix
        src/pyff/site/static/js/ds-client.js on lines 66..74

        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 69.

        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

                    lst.sort(function (a, b) { // decending order - most commonly used stuff on top
                        if (a.use_count < b.use_count) {
                            return 1;
                        }
                        if (a.use_count > b.use_count) {
        Severity: Major
        Found in src/pyff/site/static/js/ds-client.js and 1 other location - About 1 hr to fix
        src/pyff/site/static/js/ds-client.js on lines 102..110

        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 69.

        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

                return storage.onConnect().then(function () {
                    console.log(storage_key);
                    return storage.get(storage_key);
                }).then(function(data) {
                    data = data || '[]';
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js and 1 other location - About 40 mins to fix
        src/pyff/site/static/js/ds-client.js on lines 97..134

        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

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

                return storage.onConnect().then(function () {
                    console.log(storage_key);
                    return storage.get(storage_key);
                }).then(function(data) {
                    var lst = JSON.parse(data || '[]') || [];
        Severity: Minor
        Found in src/pyff/site/static/js/ds-client.js and 1 other location - About 40 mins to fix
        src/pyff/site/static/js/ds-client.js on lines 60..91

        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