getRoute(): void {
     if (this.originDestToast) {
       this.toastSvc.noOriginOrDestinationToast();
     }
    // We need an origin and destination

Close

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

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

  reload(loadedTrip): void {
    // @TODO Scroll to input area first
    this.constructMap();
    this.noLocation = false;
    // If we loaded a trip (user came via

Close

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

• Cognitive Complexity docs
• Cognitive Complexity: A new way of measuring understandability

    let transitOptions = {

Close

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.

    let directionsService = new google.maps.DirectionsService;

Close

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.

    var mapOptions = {

Close

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.

      let place =  destinationAutocomplete.getPlace();

Close

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.

    let originAutocomplete = new google.maps.places.Autocomplete(originInput);

Close

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.

  isInternetExplorer: boolean = false;

Close

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.

  * current location.  If so, get it.

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

import { Component, ViewChild, ElementRef } from '@angular/core';

Close

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.

    let destinationInput = <HTMLInputElement>document.getElementById('destination-input');

Close

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.

    let directionsService = new google.maps.DirectionsService;

Close

Rule: new-parens

Requires parentheses when invoking a constructor via the new keyword.

Rationale

Maintains stylistic consistency with other function calls.

Config

Not configurable.

Examples

"new-parens": true

For more information see this page.

    this.directionsDisplay = new google.maps.DirectionsRenderer;

Close

Rule: new-parens

Requires parentheses when invoking a constructor via the new keyword.

Rationale

Maintains stylistic consistency with other function calls.

Config

Not configurable.

Examples

"new-parens": true

For more information see this page.

    let neBound = new google.maps.LatLng(42.51138, -72.20302);

Close

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.

    let originInput = <HTMLInputElement>document.getElementById('origin-input');

Close

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.

    let loadedTrip = this.navParams.get('loadedTrip');

Close

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.

    let alert = this.alertCtrl.create({

Close

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.

  * get directions starting at the

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

import { NavController, LoadingController, AlertController, NavParams } from 'ionic-angular';

Close

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.

  * Checks whether we're trying to

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

  originInput: string = '';

Close

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.

              let closestGeolocationAddress = results[0];

Close

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.

    let options = {timeout: 5000, enableHighAccuracy: true};

Close

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.

    let swBound = new google.maps.LatLng(41.93335, -72.85809);

Close

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.

  * Otherwise, clear out the values

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

  * for origin so the user knows to type something.

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

      let place = originAutocomplete.getPlace();

Close

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.

    let destinationAutocomplete = new google.maps.places.Autocomplete(destinationInput);

Close

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.

 */

Close

Rule: jsdoc-format

Enforces basic format rules for JSDoc comments.

The following rules are enforced for JSDoc comments (comments starting with /**):

• each line contains an asterisk and asterisks must be aligned
• each asterisk must be followed by either a space or a newline (except for the first and the last)
• the only characters before the asterisk on each line must be whitespace characters
• one line comments must start with /** and end with */
• multiline comments don't allow text after /** in the first line (with option "check-multiline-start")

Rationale

Helps maintain a consistent, readable style for JSDoc comments.

Config

You can optionally specify the option "check-multiline-start" to enforce the first line of a multiline JSDoc comment to be empty.

Examples

"jsdoc-format": true

"jsdoc-format": true,check-multiline-start

Schema

{
  "type": "array",
  "minItems": 0,
  "maxItems": 1,
  "items": {
    "type": "string",
    "enum": [
      "check-multiline-start"
    ]
  }
}

For more information see this page.

    var mapOptions = {

Close

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.