SuitestAutomation/suitest-js-api

View on GitHub
lib/utils/getDeviceInfo.js

Summary

Maintainability
A
35 mins
Test Coverage
B
88%

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

function getDeviceName(deviceInfo, short = false) {
    const {manufacturer, model, customName, deviceId} = deviceInfo;

    let name;

Severity: Minor
Found in lib/utils/getDeviceInfo.js - 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

Expected blank line after variable declarations.
Open

        const response = await request([endpoints.device, {deviceId}], authorizeHttp, function(res) {
Severity: Minor
Found in lib/utils/getDeviceInfo.js by eslint

require or disallow an empty line after variable declarations (newline-after-var)

This rule was deprecated in ESLint v4.0.0 and replaced by the [padding-line-between-statements](padding-line-between-statements.md) rule.

As of today there is no consistency in separating variable declarations from the rest of the code. Some developers leave an empty line between var statements and the rest of the code like:

var foo;

// do something with foo

Whereas others don't leave any empty newlines at all.

var foo;
// do something with foo

The problem is when these developers work together in a project. This rule enforces a coding style where empty newlines are allowed or disallowed after var, let, or const statements. It helps the code to look consistent across the entire project.

Rule Details

This rule enforces a coding style where empty lines are required or disallowed after var, let, or const statements to achieve a consistent coding style across the project.

Options

This rule has a string option:

  • "always" (default) requires an empty line after var, let, or const

Comments on a line directly after var statements are treated like additional var statements.

  • "never" disallows empty lines after var, let, or const

always

Examples of incorrect code for this rule with the default "always" option:

/*eslint newline-after-var: ["error", "always"]*/
/*eslint-env es6*/

var greet = "hello,",
    name = "world";
console.log(greet, name);

let greet = "hello,",
    name = "world";
console.log(greet, name);

var greet = "hello,";
const NAME = "world";
console.log(greet, NAME);

var greet = "hello,";
var name = "world";
// var name = require("world");
console.log(greet, name);

Examples of correct code for this rule with the default "always" option:

/*eslint newline-after-var: ["error", "always"]*/
/*eslint-env es6*/

var greet = "hello,",
    name = "world";

console.log(greet, name);

let greet = "hello,",
    name = "world";

console.log(greet, name);

var greet = "hello,";
const NAME = "world";

console.log(greet, NAME);

var greet = "hello,";
var name = "world";
// var name = require("world");

console.log(greet, name);

never

Examples of incorrect code for this rule with the "never" option:

/*eslint newline-after-var: ["error", "never"]*/
/*eslint-env es6*/

var greet = "hello,",
    name = "world";

console.log(greet, name);

let greet = "hello,",
    name = "world";

console.log(greet, name);

var greet = "hello,";
const NAME = "world";

console.log(greet, NAME);

var greet = "hello,";
var name = "world";
// var name = require("world");

console.log(greet, name);

Examples of correct code for this rule with the "never" option:

/*eslint newline-after-var: ["error", "never"]*/
/*eslint-env es6*/

var greet = "hello,",
    name = "world";
console.log(greet, name);

let greet = "hello,",
    name = "world";
console.log(greet, name);

var greet = "hello,";
const NAME = "world";
console.log(greet, NAME);

var greet = "hello,";
var name = "world";
// var name = require("world");
console.log(greet, name);

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

'devices' is never reassigned. Use 'const' instead.
Open

    let devices = [];
Severity: Minor
Found in lib/utils/getDeviceInfo.js by eslint

Suggest using const (prefer-const)

If a variable is never reassigned, using the const declaration is better.

const declaration tells readers, "this variable is never reassigned," reducing cognitive load and improving maintainability.

Rule Details

This rule is aimed at flagging variables that are declared using let keyword, but never reassigned after the initial assignment.

Examples of incorrect code for this rule:

/*eslint prefer-const: "error"*/
/*eslint-env es6*/

// it's initialized and never reassigned.
let a = 3;
console.log(a);

let a;
a = 0;
console.log(a);

// `i` is redefined (not reassigned) on each loop step.
for (let i in [1, 2, 3]) {
    console.log(i);
}

// `a` is redefined (not reassigned) on each loop step.
for (let a of [1, 2, 3]) {
    console.log(a);
}

Examples of correct code for this rule:

/*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const a = 0;

// it's never initialized.
let a;
console.log(a);

// it's reassigned after initialized.
let a;
a = 0;
a = 1;
console.log(a);

// it's initialized in a different block from the declaration.
let a;
if (true) {
    a = 0;
}
console.log(a);

// it's initialized at a place that we cannot write a variable declaration.
let a;
if (true) a = 0;
console.log(a);

// `i` gets a new binding each iteration
for (const i in [1, 2, 3]) {
  console.log(i);
}

// `a` gets a new binding each iteration
for (const a of [1, 2, 3]) {
  console.log(a);
}

// `end` is never reassigned, but we cannot separate the declarations without modifying the scope.
for (let i = 0, end = 10; i < end; ++i) {
    console.log(a);
}

// suggest to use `no-var` rule.
var b = 3;
console.log(b);

Options

{
    "prefer-const": ["error", {
        "destructuring": "any",
        "ignoreReadBeforeAssign": false
    }]
}

destructuring

The kind of the way to address variables in destructuring. There are 2 values:

  • "any" (default) - If any variables in destructuring should be const, this rule warns for those variables.
  • "all" - If all variables in destructuring should be const, this rule warns the variables. Otherwise, ignores them.

Examples of incorrect code for the default {"destructuring": "any"} option:

/*eslint prefer-const: "error"*/
/*eslint-env es6*/

let {a, b} = obj;    /*error 'b' is never reassigned, use 'const' instead.*/
a = a + 1;

Examples of correct code for the default {"destructuring": "any"} option:

/*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const {a: a0, b} = obj;
const a = a0 + 1;

// all variables are reassigned.
let {a, b} = obj;
a = a + 1;
b = b + 1;

Examples of incorrect code for the {"destructuring": "all"} option:

/*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// all of `a` and `b` should be const, so those are warned.
let {a, b} = obj;    /*error 'a' is never reassigned, use 'const' instead.
                             'b' is never reassigned, use 'const' instead.*/

Examples of correct code for the {"destructuring": "all"} option:

/*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// 'b' is never reassigned, but all of `a` and `b` should not be const, so those are ignored.
let {a, b} = obj;
a = a + 1;

ignoreReadBeforeAssign

This is an option to avoid conflicting with no-use-before-define rule (without "nofunc" option). If true is specified, this rule will ignore variables that are read between the declaration and the first assignment. Default is false.

Examples of correct code for the {"ignoreReadBeforeAssign": true} option:

/*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": true}]*/
/*eslint-env es6*/

let timer;
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}
timer = setInterval(initialize, 100);

Examples of correct code for the default {"ignoreReadBeforeAssign": false} option:

/*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": false}]*/
/*eslint-env es6*/

const timer = setInterval(initialize, 100);
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}

When Not To Use It

If you don't want to be notified about variables that are never reassigned after initial assignment, you can safely disable this rule.

Related Rules

There are no issues that match your filters.

Category
Status