RSPEC-3403 is useless, and should be removed - the statement “it will always be true” is not correct, the rule therefore useless

SonarQube
, ,
1

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

First to consider: SonarQube can’t analyze at runtime, only the source at design time. So an a actual environment or case maybe an object always 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

3

Hello @RoDo777 ,

this rule in general still makes sense, because in many cases we can be quite sure that the statement is going to be true or false, even if we don’t execute the code.

Now, I don’t know why it doesn’t work properly in your case. It seems that for some reason analyzer “thinks” that it knows the type and that it is different from string. This is what we call false positive.

Are you able to create a small isolated code snippet with which you can reproduce the issue? If so, please share the reproducer and we will try to fix the problem.