radare/radare2-webui

View on GitHub
www/m/js/helpers/Table.js

Summary

Maintainability
A
3 hrs
Test Coverage

Function addRow has 49 lines of code (exceeds 25 allowed). Consider refactoring.
Open

    addRow(cells) {
        var tr = document.createElement('tr');
        this.tbody.appendChild(tr);

        for (var i = 0; i < cells.length; i++) {
Severity: Minor
Found in www/m/js/helpers/Table.js - About 1 hr to fix

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

        init() {
            this.root = document.createElement('table');
            this.root.className = 'mdl-data-table mdl-data-table--selectable mdl-shadow--2dp';
            if (this.root.id !== false) {
                this.root.id = this.id;
    Severity: Minor
    Found in www/m/js/helpers/Table.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

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

        addRow(cells) {
            var tr = document.createElement('tr');
            this.tbody.appendChild(tr);
    
            for (var i = 0; i < cells.length; i++) {
    Severity: Minor
    Found in www/m/js/helpers/Table.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

    '$' is not defined.
    Open

                $('#' + this.id).DataTable();
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    Disallow Undeclared Variables (no-undef)

    This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer).

    Rule Details

    Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment.

    Examples of incorrect code for this rule:

    /*eslint no-undef: "error"*/
    
    var a = someFunction();
    b = 10;

    Examples of correct code for this rule with global declaration:

    /*global someFunction b:true*/
    /*eslint no-undef: "error"*/
    
    var a = someFunction();
    b = 10;

    The b:true syntax in /*global */ indicates that assignment to b is correct.

    Examples of incorrect code for this rule with global declaration:

    /*global b*/
    /*eslint no-undef: "error"*/
    
    b = 10;

    By default, variables declared in /*global */ are read-only, therefore assignment is incorrect.

    Options

    • typeof set to true will warn for variables used inside typeof check (Default false).

    typeof

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

    /*eslint no-undef: "error"*/
    
    if (typeof UndefinedIdentifier === "undefined") {
        // do something ...
    }

    You can use this option if you want to prevent typeof check on a variable which has not been declared.

    Examples of incorrect code for the { "typeof": true } option:

    /*eslint no-undef: ["error", { "typeof": true }] */
    
    if(typeof a === "string"){}

    Examples of correct code for the { "typeof": true } option with global declaration:

    /*global a*/
    /*eslint no-undef: ["error", { "typeof": true }] */
    
    if(typeof a === "string"){}

    Environments

    For convenience, ESLint provides shortcuts that pre-define global variables exposed by popular libraries and runtime environments. This rule supports these environments, as listed in Specifying Environments. A few examples are given below.

    browser

    Examples of correct code for this rule with browser environment:

    /*eslint no-undef: "error"*/
    /*eslint-env browser*/
    
    setTimeout(function() {
        alert("Hello");
    });

    node

    Examples of correct code for this rule with node environment:

    /*eslint no-undef: "error"*/
    /*eslint-env node*/
    
    var fs = require("fs");
    module.exports = function() {
        console.log(fs);
    };

    When Not To Use It

    If explicit declaration of global variables is not to your taste.

    Compatibility

    This rule provides compatibility with treatment of global variables in JSHint and JSLint. Source: http://eslint.org/docs/rules/

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

                if (this.cols[c][0] == '+') {
    Severity: Minor
    Found in www/m/js/helpers/Table.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

                } else if (this.cols[c][0] == '~') {
    Severity: Minor
    Found in www/m/js/helpers/Table.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/

    Missing JSDoc comment.
    Open

        init() {
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    require JSDoc comments (require-jsdoc)

    JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

    /**
     * Adds two numbers together.
     * @param {int} num1 The first number.
     * @param {int} num2 The second number.
     * @returns {int} The sum of the two numbers.
     */
    function sum(num1, num2) {
        return num1 + num2;
    }

    Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

    Rule Details

    This rule requires JSDoc comments for specified nodes. Supported nodes:

    • "FunctionDeclaration"
    • "ClassDeclaration"
    • "MethodDefinition"
    • "ArrowFunctionExpression"

    Options

    This rule has a single object option:

    • "require" requires JSDoc comments for the specified nodes

    Default option settings are:

    {
        "require-jsdoc": ["error", {
            "require": {
                "FunctionDeclaration": true,
                "MethodDefinition": false,
                "ClassDeclaration": false,
                "ArrowFunctionExpression": false
            }
        }]
    }

    require

    Examples of incorrect code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    function foo() {
        return 10;
    }
    
    var foo = () => {
        return 10;
    }
    
    class Test{
        getDate(){}
    }

    Examples of correct code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    /**
     * It returns 10
     */
    function foo() {
        return 10;
    }
    
    /**
     * It returns test + 10
     * @params {int} test - some number
     * @returns {int} sum of test and 10
     */
    var foo = (test) => {
        return test + 10;
    }
    
    /**
     * It returns 10
     */
    var foo = () => {
        return 10;
    }
    
    /**
     * It returns 10
     */
    var foo = function() {
        return 10;
    }
    
    var array = [1,2,3];
    array.filter(function(item) {
        return item > 2;
    });
    
    /**
     * It returns 10
     */
    class Test{
        /**
        * returns the date
        */
        getDate(){}
    }
    
    setTimeout(() => {}, 10); // since it's an anonymous arrow function

    When Not To Use It

    If you do not require JSDoc for your functions, then you can leave this rule off.

    Related Rules

    Missing JSDoc comment.
    Open

        constructor(cols, nonum, id, onChange, seekNavigation = null) {
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    require JSDoc comments (require-jsdoc)

    JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

    /**
     * Adds two numbers together.
     * @param {int} num1 The first number.
     * @param {int} num2 The second number.
     * @returns {int} The sum of the two numbers.
     */
    function sum(num1, num2) {
        return num1 + num2;
    }

    Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

    Rule Details

    This rule requires JSDoc comments for specified nodes. Supported nodes:

    • "FunctionDeclaration"
    • "ClassDeclaration"
    • "MethodDefinition"
    • "ArrowFunctionExpression"

    Options

    This rule has a single object option:

    • "require" requires JSDoc comments for the specified nodes

    Default option settings are:

    {
        "require-jsdoc": ["error", {
            "require": {
                "FunctionDeclaration": true,
                "MethodDefinition": false,
                "ClassDeclaration": false,
                "ArrowFunctionExpression": false
            }
        }]
    }

    require

    Examples of incorrect code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    function foo() {
        return 10;
    }
    
    var foo = () => {
        return 10;
    }
    
    class Test{
        getDate(){}
    }

    Examples of correct code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    /**
     * It returns 10
     */
    function foo() {
        return 10;
    }
    
    /**
     * It returns test + 10
     * @params {int} test - some number
     * @returns {int} sum of test and 10
     */
    var foo = (test) => {
        return test + 10;
    }
    
    /**
     * It returns 10
     */
    var foo = () => {
        return 10;
    }
    
    /**
     * It returns 10
     */
    var foo = function() {
        return 10;
    }
    
    var array = [1,2,3];
    array.filter(function(item) {
        return item > 2;
    });
    
    /**
     * It returns 10
     */
    class Test{
        /**
        * returns the date
        */
        getDate(){}
    }
    
    setTimeout(() => {}, 10); // since it's an anonymous arrow function

    When Not To Use It

    If you do not require JSDoc for your functions, then you can leave this rule off.

    Related Rules

    Missing JSDoc comment.
    Open

        getRows() {
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    require JSDoc comments (require-jsdoc)

    JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

    /**
     * Adds two numbers together.
     * @param {int} num1 The first number.
     * @param {int} num2 The second number.
     * @returns {int} The sum of the two numbers.
     */
    function sum(num1, num2) {
        return num1 + num2;
    }

    Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

    Rule Details

    This rule requires JSDoc comments for specified nodes. Supported nodes:

    • "FunctionDeclaration"
    • "ClassDeclaration"
    • "MethodDefinition"
    • "ArrowFunctionExpression"

    Options

    This rule has a single object option:

    • "require" requires JSDoc comments for the specified nodes

    Default option settings are:

    {
        "require-jsdoc": ["error", {
            "require": {
                "FunctionDeclaration": true,
                "MethodDefinition": false,
                "ClassDeclaration": false,
                "ArrowFunctionExpression": false
            }
        }]
    }

    require

    Examples of incorrect code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    function foo() {
        return 10;
    }
    
    var foo = () => {
        return 10;
    }
    
    class Test{
        getDate(){}
    }

    Examples of correct code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    /**
     * It returns 10
     */
    function foo() {
        return 10;
    }
    
    /**
     * It returns test + 10
     * @params {int} test - some number
     * @returns {int} sum of test and 10
     */
    var foo = (test) => {
        return test + 10;
    }
    
    /**
     * It returns 10
     */
    var foo = () => {
        return 10;
    }
    
    /**
     * It returns 10
     */
    var foo = function() {
        return 10;
    }
    
    var array = [1,2,3];
    array.filter(function(item) {
        return item > 2;
    });
    
    /**
     * It returns 10
     */
    class Test{
        /**
        * returns the date
        */
        getDate(){}
    }
    
    setTimeout(() => {}, 10); // since it's an anonymous arrow function

    When Not To Use It

    If you do not require JSDoc for your functions, then you can leave this rule off.

    Related Rules

    Missing JSDoc comment.
    Open

        insertInto(node) {
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    require JSDoc comments (require-jsdoc)

    JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

    /**
     * Adds two numbers together.
     * @param {int} num1 The first number.
     * @param {int} num2 The second number.
     * @returns {int} The sum of the two numbers.
     */
    function sum(num1, num2) {
        return num1 + num2;
    }

    Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

    Rule Details

    This rule requires JSDoc comments for specified nodes. Supported nodes:

    • "FunctionDeclaration"
    • "ClassDeclaration"
    • "MethodDefinition"
    • "ArrowFunctionExpression"

    Options

    This rule has a single object option:

    • "require" requires JSDoc comments for the specified nodes

    Default option settings are:

    {
        "require-jsdoc": ["error", {
            "require": {
                "FunctionDeclaration": true,
                "MethodDefinition": false,
                "ClassDeclaration": false,
                "ArrowFunctionExpression": false
            }
        }]
    }

    require

    Examples of incorrect code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    function foo() {
        return 10;
    }
    
    var foo = () => {
        return 10;
    }
    
    class Test{
        getDate(){}
    }

    Examples of correct code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    /**
     * It returns 10
     */
    function foo() {
        return 10;
    }
    
    /**
     * It returns test + 10
     * @params {int} test - some number
     * @returns {int} sum of test and 10
     */
    var foo = (test) => {
        return test + 10;
    }
    
    /**
     * It returns 10
     */
    var foo = () => {
        return 10;
    }
    
    /**
     * It returns 10
     */
    var foo = function() {
        return 10;
    }
    
    var array = [1,2,3];
    array.filter(function(item) {
        return item > 2;
    });
    
    /**
     * It returns 10
     */
    class Test{
        /**
        * returns the date
        */
        getDate(){}
    }
    
    setTimeout(() => {}, 10); // since it's an anonymous arrow function

    When Not To Use It

    If you do not require JSDoc for your functions, then you can leave this rule off.

    Related Rules

    Missing JSDoc comment.
    Open

        addRow(cells) {
    Severity: Minor
    Found in www/m/js/helpers/Table.js by eslint

    require JSDoc comments (require-jsdoc)

    JSDoc is a JavaScript API documentation generator. It uses specially-formatted comments inside of code to generate API documentation automatically. For example, this is what a JSDoc comment looks like for a function:

    /**
     * Adds two numbers together.
     * @param {int} num1 The first number.
     * @param {int} num2 The second number.
     * @returns {int} The sum of the two numbers.
     */
    function sum(num1, num2) {
        return num1 + num2;
    }

    Some style guides require JSDoc comments for all functions as a way of explaining function behavior.

    Rule Details

    This rule requires JSDoc comments for specified nodes. Supported nodes:

    • "FunctionDeclaration"
    • "ClassDeclaration"
    • "MethodDefinition"
    • "ArrowFunctionExpression"

    Options

    This rule has a single object option:

    • "require" requires JSDoc comments for the specified nodes

    Default option settings are:

    {
        "require-jsdoc": ["error", {
            "require": {
                "FunctionDeclaration": true,
                "MethodDefinition": false,
                "ClassDeclaration": false,
                "ArrowFunctionExpression": false
            }
        }]
    }

    require

    Examples of incorrect code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    function foo() {
        return 10;
    }
    
    var foo = () => {
        return 10;
    }
    
    class Test{
        getDate(){}
    }

    Examples of correct code for this rule with the { "require": { "FunctionDeclaration": true, "MethodDefinition": true, "ClassDeclaration": true, "ArrowFunctionExpression": true } } option:

    /*eslint "require-jsdoc": ["error", {
        "require": {
            "FunctionDeclaration": true,
            "MethodDefinition": true,
            "ClassDeclaration": true
        }
    }]*/
    
    /**
     * It returns 10
     */
    function foo() {
        return 10;
    }
    
    /**
     * It returns test + 10
     * @params {int} test - some number
     * @returns {int} sum of test and 10
     */
    var foo = (test) => {
        return test + 10;
    }
    
    /**
     * It returns 10
     */
    var foo = () => {
        return 10;
    }
    
    /**
     * It returns 10
     */
    var foo = function() {
        return 10;
    }
    
    var array = [1,2,3];
    array.filter(function(item) {
        return item > 2;
    });
    
    /**
     * It returns 10
     */
    class Test{
        /**
        * returns the date
        */
        getDate(){}
    }
    
    setTimeout(() => {}, 10); // since it's an anonymous arrow function

    When Not To Use It

    If you do not require JSDoc for your functions, then you can leave this rule off.

    Related Rules

    There are no issues that match your filters.

    Category
    Status