SonarSource / eslint-plugin-sonarjs

SonarJS rules for ESLint

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

S4144 (`no-identical-functions`) ignores arrow function if not part of variable declaration

cheungpat opened this issue · comments

I want to report a bug.

Reproducer

        setTimeout(() => {
          console.log("Hello");
          console.log("World");
          return 42;
        }, 100);
        setTimeout(() => {
          console.log("Hello");
          console.log("World");
          return 42;
        }, 100);

Expected behavior

In the above situation, the two arrow functions should be flagged as identical. In the current rule implementation, these arrow functions are only flagged as identical if they are an expression assigned to a variable.

eslint-plugin-sonarjs version: v0.19.0

eslint version: v8.20.0

Node.js version: v16.17.1

Rule key: sonarjs/no-identical-functions

Hello @cheungpat,

Thank you for your interest in this rule. However, we have declared this pattern as an exception as you can see at the bottom of the rule description: https://rules.sonarsource.com/javascript/RSPEC-4144/
This was done because anonymous functions often contain duplicate code which we deem not necessary to modularize in a variable.

However, we have declared this pattern as an exception as you can see at the bottom of the rule description: https://rules.sonarsource.com/javascript/RSPEC-4144/

I didn’t read this exception, thank you for pointing this out to me. I understand why this exception is put in place; I am not a big fan of this check either.

The problem is that I am working in an environment where the sonar instance flag unnamed arrow function as duplicated functions, and I have little influence in how the rules are applied. It is also likely that the sonar instance is outdated and the rule definition has been updated since then.

Not sure if you are interested in having an option to enable this check? Otherwise, I probably would just close this issue and the associated PR.

commented

Hello @cheungpat ,
Currently, we think that this exception makes sense, but we might revisit it in the future.