RSPEC-3403 FP The "prop" in "for (prop in object)" is not considered a string

In this example

for (prop in object) {
  if (prop !== 'something') { // FP

The line marked with FP is where the false positive is shown, with the message:

Remove this “!==” check; it will always be true. Did you mean to use “!=”?

which corresponds to this rule: JavaScript static code analysis: Strict equality operators should not be used with dissimilar types

BUT “prop” does hold a string.

As a side note, in 2021 nobody should suggest to use anything but “===” / “!==”.

  • Versions: SonarQube 8.9, Scanner 4.6.2

Hello,

I can’t reproduce, could you provide a self-containing code example?
Is it JS or TS file?

I will suggest that the rule RSPEC-3403 is useless, and should be removed, here is why.

First what you always should consider: SonarQube can’t analyze at runtime, only the source at design time. So if in your environment or case maybe always it will be a string, but SQ can’t know this, because it cant ‘debug’ or ‘run’ your code.

I write here, because we had a discussion about [RSPEC-3403].
This statement “it will always be true” is not correct. And because === does check type and value on both sides, the rule is senseless.

So the rule itself should be removed we believe in our team. Why?

Look at this example:

            if ($currentClickedElement.data("switch") === "map") {
                // do something
            }

the compare operator ‘===’ means:

  1. to be true, both sides must be from the same type and value

  2. on the right side of the expression, the constant “map” is definitely of type ‘string’

  3. on the left side you don’t know what type the value is at design time
    3.1 but it CAN be of type ‘string’
    3.1.1 so the statement “it will always be true” is not correct.
    3.1.2 a statement like ‘it will sometimes be true’ is sensless, because this is why the ‘if’ clause exists

@RoDo777 please don’t post on unrelated topics, I see you already created this one RSPEC-3403 is useless, and should be removed - the statement “it will always be true” is not correct, the rule therefore useless

@saberduck This is a special answer to aercolino, because (I believe) that he thinks sonarqube analyzes at runtime:

BUT [“prop” does hold a string].
And Lena can’t reproduce, because the question was confusing

Btw: Is someone looking at my bug report
(RSPEC-3403 is useless, and should be removed - the statement “it will always be true” is not correct, the rule therefore useless)