SonarCloud isn't recognizing all 'Constructor has x parameters, which is greater than the 7 authorized.' issues?

Hi,

We are using SonarCloud on our C# projects in a default configuration. (we use the Sonar Way profile for c#)

There are some legacy controllers in our code base that had accumulated a lot of parameters in the constructor. So we noticed having a lot of csharpsquid:S107 rules that needed some attention.
But when fixing them we noticed some of the ‘controllers’ had not been detected as having an issue.

Weird behavior here is that when using inheritance, you get extra parameters for free:

image

I’ve also tested this behaviour with SonarLint in VS2022 (v5.3.0.41207). (I didn’t connect to our sonarcloud project, to make sure we get default behavior)

So my question:
Is this default behavior I’m not aware of or is this just a bug?

If it isn’t a bug, do you have suggestions how to make people aware in our team that even in these situations to keep their constructors/methods nice and tidy?

– Fred

Code for copy paste:

    public class Class1 {
        public Class1(int one) { }
    }

    public class Class2
    {
        public Class2(int one, int two, int three, int four,
            int five, int six, int seven, int eight)
        {
        }
    }

    public class Class3 : Class1
    {
        public Class3(int one, int two, int three, int four,
            int five, int six, int seven, int eight) : base(one)
        {
        }
    }

    public class Class4 : Class1
    {
        public Class4(int one, int two, int three, int four,
            int five, int six, int seven, int eight, int nine) : base(one)
        {
        }
    }
1 Like

+1
Same thing is happening to me as well

Hello,

This is expected behavior for rule S107. The parameters intended for the base constructor do not count in the total sum of parameters given to the child constructor.

The parameter limit default value is 7, so, in the case of Class2 this is exceeded, and an issue is raised. But for Class3, the total sum is 7 because parameter one is needed as input for the base class, so it does not count.

If you need to raise the issue for fewer input parameters, you can always change the limit for rule S107 through a custom quality profile in SonarCloud or SonarQube.

Best Regards,
Mary

Hi Mary,

If that is expected behavior, shouldn’t this be added to the documentation of rule S107? The documentation for this rule is a bit thin anyway. Are there more expected behaviors that’s not in the documentation? I was kinda surprised with this and this took me a bit of time to figure out before posting something on the forum here.

Personally, this ‘expected behavior’ makes it easy to cheat the rule and not just fix the issue behind it.

We don’t want to change the rule for this, we where just surprised by the handling of this.

I’m curious about your opinion on this!

Best regards,
Freddy

Hello Freddy,

You are right.
Apologies for not having updated the description and the confusion that this has caused. It will be fixed soon.

The reason behind the decision not to count the input parameters for the base class is to reduce the noise that the false-positive issues were causing.

We are aware of the limitations of this rule in this form but it’s a bit hard to find the right balance between too strict and too permissive.

Best Regards,
Mary

1 Like

Hi Mary,

No worries, I think there will always be a discussion about the rules.
But with updating the documentation for this rule I think most discussion will be resolved.

Thanks for you time explaining this.

Best regards,
Freddy

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.