SonarQube version: 9.1 community edition
Scanning method: Azure DevOps pipelines
In the world of ASP.NET with Dependency Injection, the rule for how many parameters is too many parameters doesn’t really work all that well when it is applied to a constructor.
I whole heartedly agree with it as a rule to be applied to conventional methods, but as a rule for constructors it seems to contradict the dependency injection pattern.
There are many arguable cases where having more than 7 parameters in a constructor is a valid use case - such as manager layers in ASP.NET APIs.
Is there a way that this rule could be isolated to parameters only and not the constructors?
Why do you think a class should have that many dependencies? If a class (DI or not) has that many, I would argue that is time to reconsider it’s responsibilities, as it probably has too many. (And I think, that is what this rule is about)
Hey @Corniel - I would usually agree with you completely.
In my case in particular, we introduce many helpers which we invoke from our manager. These helpers exist to allow us to do things like implement adapters to convert from API requests to internal models that we actually interact with.
Furthermore, our API is robustly built with feature managers for new features we release which is integrated with LaunchDarkly. Essentially, with every new feature, where there may be business specific-logic to our application, we will introduce helpers that manager the new feature we are developing. We then pass on API manager layer to these helpers and take those results and either read/write to a DB. These helpers, aside from managing techniques such as feature toggles, also have redundancy built-in with retry policies and circuit breaker patterns so as to fail transiently without bringing down our surrounding ecosystem and retry when the ecosystem becomes available.
As a result, our manager ends up with a handful of dependencies for the database calls, along with dependencies for the helpers for all our features.
So in 99.99% of our development, we follow the rule strictly, in this particular case the rule doesn’t work for us and we are finding this is becoming more and more common as we develop software in a way that allows to safely separate deployment from release. I am sure that there are other teams out there facing this issue as we expand our DevOps capabilities.
Just wondered if it’s possible to configure/split this particular rule for C# to be 1 for constructors and 1 for method parameters.
Hope this answers your question?
To prevent any misunderstanding, I’m not working for SonarSource, I’m just a happy coder (that have done some contributions to the Sonar .NET analyzers). So, it my personal opinion I’m sharing here.
To me, having one exception to the rule, is not a reason to abandon it. It is reason to document why, in this particular case, you intentionally violated it. So, that your later self, or (even more likely, you future colleague) can challenge, or re-evaluate the decision made.
That being said, It might be worth, to group some of these dependencies related to those feature managers, and inject them at once. That obviously only helps if, and only if, that does not increase the number of violations.
Personally I would like to see this rule “split” into two, either two separate rules or just a rule with multiple thresholds. So we could have separate values for methods and constructors, and possibly separate severity levels.