False-positive for S1854 when setting values that are suppossed to be excepted from rule

SonarQube for IDE Visual Studio
,
1
  • Language: C#
  • Rule: S1854
  • Product: SonarQube for Visual Studio 8.9.0.11507
  • IDE: Visual Studio Community 2022 17.12.3
  • Connected mode: No

According to the documentation of rule S1854 (“Unused assignments should be removed”):

No issue is reported when […] it’s an initialization to -1, 0, 1, null, true, false, "" or string.Empty

Which, personally, I’d argue is a good exception for the rule. However, that doesn’t seem to be the case, as the rule is reported when setting variables to those values, as in this C# code:

internal static class Program
{
    static void Main()
    {
        string someString1 = "Meow";
        string someString2 = "Meow";
        string someString3 = "Meow";
        int someInt1 = 123;
        int someInt2 = 123;
        int someInt3 = 123;
        bool someBool1 = false;
        bool someBool2 = true;

        Console.WriteLine(someString1);
        Console.WriteLine(someString2);
        Console.WriteLine(someString3);
        Console.WriteLine(someInt1);
        Console.WriteLine(someInt2);
        Console.WriteLine(someInt3);
        Console.WriteLine(someBool1);
        Console.WriteLine(someBool2);

        // These generate S1854:
        someString1 = null;
        someString2 = "";
        someString3 = string.Empty;
        someInt1 = -1;
        someInt2 = 0;
        someInt3 = 1;
        someBool1 = true;
        someBool2 = false;
    }
}

All the assignments at the end report the rule.

This report is related: S1854 False Positive

4

Hi @Trisibo,

Happy new year and thanks for the feedback!

I don’t think I agree that this is an FP.

The rule states that:

No issue is reported when […] it’s an initialization to -1, 0, 1, null, true, false, "" or string.Empty

The key word being initialization. These variables are not initialized to null, and as such I believe the rule should raise.

My view would be that in general setting a value to null after it is finished being used is a useless assignment and this issue should raise.

There are of course scenarios where this isn’t the case (e.g. the example you linked) and they can be marked as ‘Accepted’ when they arise.

5

Happy new year, @alexander.meseldzija.

Indeed, I misinterpreted “initialization” as “assignment”, sorry about that.

I still think those assignments (plus “++variable” and similar) can make code a bit clearer in some situations, even if they are technically useless, though that’s of course subjective, and the rule works as intended. I believe marking issues as “Accepted” only works in connected mode, so the only option when not connected would be to use #pragma warning disable (or just disable the rule entirely, which is not ideal), right? Does SonarQube have some mechanism to “tweak” rules, and is it possible to suggest an option to allow those exceptions?

Thanks!

6

Hi @Trisibo,
Glad I could help.

We do have customisation of some rules via parameters, but unfortunately in this case, I believe the only solutions available for you are to disable the rule, or to use #pragma.

While we do have some rules that handle parameters to tweak the rules, doing so for every rule in every language isn’t fully viable. The current mechanism for handling rules that don’t quite fit, and aren’t applicable in certain contexts would be marking them as accepted where required.