This is a global question I keep asking myself recurently.
We have many different projects under Analysis in SonarCloud, on different technologies, but mainly .Net, PHP, and NG.
I’m alway asked if I can customize the analysis rules, modify Severity, or increase the threshold, etc.
Sure I can do it, but at the end, I get different quality profiles for different projects, and the guys that work with the default profile ask me also to switch to another profile that is more easy to comply with.
Also, if we don’t apply same rules for the different projects, it’s more complicated to compare them.
There is not a real consensus for each rule, and depending on the developer, the rule is seen as too restrictive or too complex to comply with. Sometimes, devs say if we have to comply to the rules, it will take more time.
How do you deal with that ? The option to have no custom rule and to stick with the default profile for everyone seems a good option to me. Same rules for all. does it make sense ?
The default, built-in Quality Profiles are a set of no-brainer, non-controversial rules that should apply to every project. These are, coincidentally, the rules we dedicate the most time to developing and fine-tuning. (We also consider these guidelines when determining rule severity, it’s not random).
We’re always happy to be challenged on what it’s in the default Quality Profiles (and the severities, and thresholds…), but we’ve gotten pretty good at it.
Inevitably, some projects will have different requirements and want a custom ruleset. Flexibility is important, but we encourage users to keep customized Quality Profiles to a minimum. The goal should be finding consistent standards to apply to your organization’s projects. There are also other ways for users to suppress issues (like marking issues as False-Positive/Won’t Fix, or setting exclusions at a project level).
If your developers are feeling overwhelmed, make sure that they are following the Clean as You Code methodology and focusing on the new code that they’re writing, not all the issues that SonarCloud has raised. This should counter any “it takes too much time argument” – it’s just following the boy scout rule: leave code cleaner than you found it, and don’t add any new mess.
