The handling of this rule by marking it as deprecated was inappropriate. The reason given was because some customers found it noisy or didnt like it.
The rule is there because there is official guidance from MSFT that has been published for > 10 years recommending it.
If this was a problem for customers who did not want to adhere to the guidance they could just deactivate the rule.
If enough customers complained about the rule, SonarSource could have removed it from the sonar way profile.
Instead it was marked as deprecated, which is a status that is shown to every user of a quality profile by highlighting the QP as a big red failure.
This immediately puts into question the validity of the quality profile. Why should programmers trust that their code is being evaluated correctly when the evaluation rules are marked as having some kind of problem? They shouldn’t, and don’t - which can undo any progress made in trying to get an enterprise codebase up to snuff. Please address this by following the advice in the title, or at least stop undermining the adoption and usage of Sonarcloud and remove all the deprecation highlights visible to all users.
would have been clearer as “could have just removed it”
its not that its deprecated and in sonar way, its that it was marked as deprecated instead of just removing it from the sonar way.
The sonar quality profile that we have refined to best match our coding standards has this rule and even though its a legitimate, applicable, and usable rule the quality profile is displayed on all screens and to all users as if it has a problem.
and it’s not part of SonarWay.