Sign upLogin

umts/pvta-multiplatform

View on GitHub
Star
src/pages/routes-and-stops/routes-and-stops.component.ts

Summary

Maintainability
C
1 day
Test Coverage

File routes-and-stops.component.ts has 273 lines of code (exceeds 250 allowed). Consider refactoring.
Open

import { Component } from '@angular/core';
import { NavController, LoadingController, AlertController } from 'ionic-angular';
import { Storage } from '@ionic/storage';
import { Geolocation } from '@ionic-native/geolocation';
import { RouteService } from '../../providers/route.service';
Severity: Minor
Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 2 hrs to fix

    Function toggleOrdering has 55 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

      toggleOrdering(): void {
    this.onSearchQueryChanged(this.searchQuery);
    var routeOrderings = ['favorites', 'name'];
    var stopOrderings = ['favorites', 'distance'];
    let primarySort: string;
    Severity: Major
    Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 2 hrs to fix

      Function toggleOrdering has a Cognitive Complexity of 13 (exceeds 5 allowed). Consider refactoring.
      Open

        toggleOrdering(): void {
    this.onSearchQueryChanged(this.searchQuery);
    var routeOrderings = ['favorites', 'name'];
    var stopOrderings = ['favorites', 'distance'];
    let primarySort: string;
      Severity: Minor
      Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 1 hr to fix

      Cognitive Complexity

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

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

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

      Further reading

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

        calculateStopDistances(position?): void {
    if (position) {
      var currentPosition = {
        latitude: position.coords.latitude,
        longitude: position.coords.longitude
      Severity: Minor
      Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 1 hr to fix

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

          calculateStopDistances(position?): void {
    if (position) {
      var currentPosition = {
        latitude: position.coords.latitude,
        longitude: position.coords.longitude
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 45 mins to fix

        Cognitive Complexity

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

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

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

        Further reading

        Function onSearchQueryChanged has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring.
        Open

          onSearchQueryChanged(query: string): void {
    if (!query || query === '') {
      this.routesDisp = this.routes;
      this.stopsDisp = this.stops;
      this.searchQuery = '';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts - About 35 mins to fix

        Cognitive Complexity

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

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

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

        Further reading

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

            var routeOrderings = ['favorites', 'name'];
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

                var msg = 'Current position found, but no previous position or has moved; calculating stop distances.';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

                  var lons = Math.pow(stop.Longitude - position.coords.longitude, 2);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Identifier 'newDistance' is never reassigned; use 'const' instead of 'var'.
        Open

                  var newDistance = Math.sqrt(lats + lons);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Identifier 'options' is never reassigned; use 'const' instead of 'let'.
        Open

              let options = {timeout: 5000, enableHighAccuracy: true};
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Identifier 'fr' is never reassigned; use 'const' instead of 'let'.
        Open

            let fr: Promise<any> = this.getfavRoutes();
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

                  var lats = Math.pow(stop.Latitude - position.coords.latitude, 2);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Identifier 'stopOrderings' is never reassigned; use 'const' instead of 'var'.
        Open

            var stopOrderings = ['favorites', 'distance'];
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Type string trivially inferred from a string literal, remove type annotation
        Open

          searchQuery: string = '';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-inferrable-types

        Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.

        Rationale

        Explicit types where they can be easily inferred by the compiler make code more verbose.

        Notes
        • TypeScript Only
        • Has Fix

        Config

        Two arguments may be optionally provided:

        • ignore-params allows specifying an inferrable type annotation for function params. This can be useful when combining with the typedef rule.
        • ignore-properties allows specifying an inferrable type annotation for class properties.
        Examples
        "no-inferrable-types": true
        "no-inferrable-types": true,ignore-params
        "no-inferrable-types": true,ignore-params,ignore-properties
        Schema
        {
  "type": "array",
  "items": {
    "type": "string",
    "enum": [
      "ignore-params",
      "ignore-properties"
    ]
  },
  "minLength": 0,
  "maxLength": 2
}

        For more information see this page.

        Type boolean trivially inferred from a boolean literal, remove type annotation
        Open

          isInternetExplorer: boolean = false;
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-inferrable-types

        Disallows explicit type declarations for variables or parameters initialized to a number, string, or boolean.

        Rationale

        Explicit types where they can be easily inferred by the compiler make code more verbose.

        Notes
        • TypeScript Only
        • Has Fix

        Config

        Two arguments may be optionally provided:

        • ignore-params allows specifying an inferrable type annotation for function params. This can be useful when combining with the typedef rule.
        • ignore-properties allows specifying an inferrable type annotation for class properties.
        Examples
        "no-inferrable-types": true
        "no-inferrable-types": true,ignore-params
        "no-inferrable-types": true,ignore-params,ignore-properties
        Schema
        {
  "type": "array",
  "items": {
    "type": "string",
    "enum": [
      "ignore-params",
      "ignore-properties"
    ]
  },
  "minLength": 0,
  "maxLength": 2
}

        For more information see this page.

        Identifier 'routeOrderings' is never reassigned; use 'const' instead of 'var'.
        Open

            var routeOrderings = ['favorites', 'name'];
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Identifier 'msg' is never reassigned; use 'const' instead of 'var'.
        Open

                var msg = 'Current position found, but no previous position or has moved; calculating stop distances.';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

              var currentPosition = {
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Identifier 'fs' is never reassigned; use 'const' instead of 'let'.
        Open

            let fs: Promise<any> = this.getfavStops();
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Identifier 'currentPosition' is never reassigned; use 'const' instead of 'var'.
        Open

              var currentPosition = {
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Named imports must be alphabetized.
        Open

        import { FavoriteStopService, FavoriteStopModel } from '../../providers/favorite-stop.service';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: ordered-imports

        Requires that import statements be alphabetized and grouped.

        Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.

        Notes
        • Has Fix

        Config

        You may set the "import-sources-order" option to control the ordering of source imports (the "foo" in import {A, B, C} from "foo").

        Possible values for "import-sources-order" are:

        • "case-insensitive': Correct order is "Bar", "baz", "Foo". (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is "baz", "Bar", "Foo".
        • "lowercase-last": Correct order is "Bar", "Foo", "baz".
        • "any": Allow any order.

        You may set the "grouped-imports" option to control the grouping of source imports (the "foo" in import {A, B, C} from "foo"). The grouping used is controlled by the "groups" option.

        Possible values for "grouped-imports" are:

        • false: Do not enforce grouping. (This is the default.)
        • true: Group source imports using default grouping or groups setting.

        The value of "groups" is a list of group rules of the form:

        [{
    "name": "optional rule name",
    "match": "regex string",
    "order": 10
}, {
    "name": "pkga imports",
    "match": "^@pkga",
    "order": 20
}]

        there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list

        ["^@pkga", "^\.\."]

        The first rule in the list to match a given import is the group that is used. If no rule in matched then the import will be put in an unmatched group at the end of all groups. The groups must be ordered based upon the sequential value of the order value. (ie. order 0 is first)

        If no "groups" options is set, a default grouping is used of third-party, parent directories and the current directory. ("bar", "../baz", "./foo".)

        You may set the "named-imports-order" option to control the ordering of named imports (the {A, B, C} in import {A, B, C} from "foo").

        Possible values for "named-imports-order" are:

        • "case-insensitive': Correct order is {A, b, C}. (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is {b, A, C}.
        • "lowercase-last": Correct order is {A, C, b}.
        • "any": Allow any order.

        You may set the "module-source-path" option to control the ordering of imports based full path or just the module name

        Possible values for "module-source-path" are:

        • "full': Correct order is "./a/Foo", "./b/baz", "./c/Bar". (This is the default.)
        • "basename": Correct order is "./c/Bar", "./b/baz", "./a/Foo".
        Examples
        "ordered-imports": true
        "ordered-imports": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "grouped-imports": {
      "type": "boolean"
    },
    "groups": {
      "type": "list",
      "listType": {
        "oneOf": [
          {
            "type": "string"
          },
          {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "match": {
                "type": "string"
              },
              "order": {
                "type": "number"
              }
            },
            "required": [
              "match",
              "order"
            ]
          }
        ]
      }
    },
    "import-sources-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "named-imports-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "module-source-path": {
      "type": "string",
      "enum": [
        "full",
        "basename"
      ]
    }
  },
  "additionalProperties": false
}

        For more information see this page.

        Identifier 'stop' is never reassigned; use 'const' instead of 'let'.
        Open

                for (let stop of this.stops) {
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

                  var newDistance = Math.sqrt(lats + lons);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Identifier 'lats' is never reassigned; use 'const' instead of 'var'.
        Open

                  var lats = Math.pow(stop.Latitude - position.coords.latitude, 2);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Forbidden 'var' keyword, use 'let' or 'const' instead
        Open

            var stopOrderings = ['favorites', 'distance'];
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: no-var-keyword

        Disallows usage of the var keyword.

        Use let or const instead.

        Rationale

        Declaring variables using var has several edge case behaviors that make var unsuitable for modern code. Variables declared by var have their parent function block as their scope, ignoring other control flow statements. vars have declaration "hoisting" (similar to functions) and can appear to be used before declaration.

        Variables declared by const and let instead have as their scope the block in which they are defined, and are not allowed to used before declaration or be re-declared with another const or let.

        Notes
        • Has Fix

        Config

        Not configurable.

        Examples
        "no-var-keyword": true

        For more information see this page.

        Identifier 'lons' is never reassigned; use 'const' instead of 'var'.
        Open

                  var lons = Math.pow(stop.Longitude - position.coords.longitude, 2);
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: prefer-const

        Requires that variable declarations use const instead of let and var if possible.

        If a variable is only assigned to once when it is declared, it should be declared using 'const'

        Notes
        • Has Fix

        Config

        An optional object containing the property "destructuring" with two possible values:

        • "any" (default) - If any variable in destructuring can be const, this rule warns for those variables.
        • "all" - Only warns if all variables in destructuring can be const.
        Examples
        "prefer-const": true
        "prefer-const": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "destructuring": {
      "type": "string",
      "enum": [
        "all",
        "any"
      ]
    }
  }
}

        For more information see this page.

        Named imports must be alphabetized.
        Open

        import { NavController, LoadingController, AlertController } from 'ionic-angular';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: ordered-imports

        Requires that import statements be alphabetized and grouped.

        Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.

        Notes
        • Has Fix

        Config

        You may set the "import-sources-order" option to control the ordering of source imports (the "foo" in import {A, B, C} from "foo").

        Possible values for "import-sources-order" are:

        • "case-insensitive': Correct order is "Bar", "baz", "Foo". (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is "baz", "Bar", "Foo".
        • "lowercase-last": Correct order is "Bar", "Foo", "baz".
        • "any": Allow any order.

        You may set the "grouped-imports" option to control the grouping of source imports (the "foo" in import {A, B, C} from "foo"). The grouping used is controlled by the "groups" option.

        Possible values for "grouped-imports" are:

        • false: Do not enforce grouping. (This is the default.)
        • true: Group source imports using default grouping or groups setting.

        The value of "groups" is a list of group rules of the form:

        [{
    "name": "optional rule name",
    "match": "regex string",
    "order": 10
}, {
    "name": "pkga imports",
    "match": "^@pkga",
    "order": 20
}]

        there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list

        ["^@pkga", "^\.\."]

        The first rule in the list to match a given import is the group that is used. If no rule in matched then the import will be put in an unmatched group at the end of all groups. The groups must be ordered based upon the sequential value of the order value. (ie. order 0 is first)

        If no "groups" options is set, a default grouping is used of third-party, parent directories and the current directory. ("bar", "../baz", "./foo".)

        You may set the "named-imports-order" option to control the ordering of named imports (the {A, B, C} in import {A, B, C} from "foo").

        Possible values for "named-imports-order" are:

        • "case-insensitive': Correct order is {A, b, C}. (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is {b, A, C}.
        • "lowercase-last": Correct order is {A, C, b}.
        • "any": Allow any order.

        You may set the "module-source-path" option to control the ordering of imports based full path or just the module name

        Possible values for "module-source-path" are:

        • "full': Correct order is "./a/Foo", "./b/baz", "./c/Bar". (This is the default.)
        • "basename": Correct order is "./c/Bar", "./b/baz", "./a/Foo".
        Examples
        "ordered-imports": true
        "ordered-imports": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "grouped-imports": {
      "type": "boolean"
    },
    "groups": {
      "type": "list",
      "listType": {
        "oneOf": [
          {
            "type": "string"
          },
          {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "match": {
                "type": "string"
              },
              "order": {
                "type": "number"
              }
            },
            "required": [
              "match",
              "order"
            ]
          }
        ]
      }
    },
    "import-sources-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "named-imports-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "module-source-path": {
      "type": "string",
      "enum": [
        "full",
        "basename"
      ]
    }
  },
  "additionalProperties": false
}

        For more information see this page.

        Named imports must be alphabetized.
        Open

        import { FavoriteRouteService, FavoriteRouteModel } from '../../providers/favorite-route.service';
        Severity: Minor
        Found in src/pages/routes-and-stops/routes-and-stops.component.ts by tslint

        Rule: ordered-imports

        Requires that import statements be alphabetized and grouped.

        Enforce a consistent ordering for ES6 imports: - Named imports must be alphabetized (i.e. "import {A, B, C} from "foo";") - The exact ordering can be controlled by the named-imports-order option. - "longName as name" imports are ordered by "longName". - Import sources must be alphabetized within groups, i.e.: import * as foo from "a"; import * as bar from "b"; - Groups of imports are delineated by blank lines. You can use this rule to group imports however you like, e.g. by first- vs. third-party or thematically or you can define groups based upon patterns in import path names.

        Notes
        • Has Fix

        Config

        You may set the "import-sources-order" option to control the ordering of source imports (the "foo" in import {A, B, C} from "foo").

        Possible values for "import-sources-order" are:

        • "case-insensitive': Correct order is "Bar", "baz", "Foo". (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is "baz", "Bar", "Foo".
        • "lowercase-last": Correct order is "Bar", "Foo", "baz".
        • "any": Allow any order.

        You may set the "grouped-imports" option to control the grouping of source imports (the "foo" in import {A, B, C} from "foo"). The grouping used is controlled by the "groups" option.

        Possible values for "grouped-imports" are:

        • false: Do not enforce grouping. (This is the default.)
        • true: Group source imports using default grouping or groups setting.

        The value of "groups" is a list of group rules of the form:

        [{
    "name": "optional rule name",
    "match": "regex string",
    "order": 10
}, {
    "name": "pkga imports",
    "match": "^@pkga",
    "order": 20
}]

        there is also a simplified form where you only pass a list of patterns and the order is given by the position in the list

        ["^@pkga", "^\.\."]

        The first rule in the list to match a given import is the group that is used. If no rule in matched then the import will be put in an unmatched group at the end of all groups. The groups must be ordered based upon the sequential value of the order value. (ie. order 0 is first)

        If no "groups" options is set, a default grouping is used of third-party, parent directories and the current directory. ("bar", "../baz", "./foo".)

        You may set the "named-imports-order" option to control the ordering of named imports (the {A, B, C} in import {A, B, C} from "foo").

        Possible values for "named-imports-order" are:

        • "case-insensitive': Correct order is {A, b, C}. (This is the default.)
        • "case-insensitive-legacy': Correct order is "Bar", "baz", "Foo".
        • "lowercase-first": Correct order is {b, A, C}.
        • "lowercase-last": Correct order is {A, C, b}.
        • "any": Allow any order.

        You may set the "module-source-path" option to control the ordering of imports based full path or just the module name

        Possible values for "module-source-path" are:

        • "full': Correct order is "./a/Foo", "./b/baz", "./c/Bar". (This is the default.)
        • "basename": Correct order is "./c/Bar", "./b/baz", "./a/Foo".
        Examples
        "ordered-imports": true
        "ordered-imports": true,[object Object]
        Schema
        {
  "type": "object",
  "properties": {
    "grouped-imports": {
      "type": "boolean"
    },
    "groups": {
      "type": "list",
      "listType": {
        "oneOf": [
          {
            "type": "string"
          },
          {
            "type": "object",
            "properties": {
              "name": {
                "type": "string"
              },
              "match": {
                "type": "string"
              },
              "order": {
                "type": "number"
              }
            },
            "required": [
              "match",
              "order"
            ]
          }
        ]
      }
    },
    "import-sources-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "named-imports-order": {
      "type": "string",
      "enum": [
        "case-insensitive",
        "case-insensitive-legacy",
        "lowercase-first",
        "lowercase-last",
        "any"
      ]
    },
    "module-source-path": {
      "type": "string",
      "enum": [
        "full",
        "basename"
      ]
    }
  },
  "additionalProperties": false
}

        For more information see this page.

        There are no issues that match your filters.

        Category
        Status