Just wrapped up a 14-day POC of SonarQube (Cloud) for a new project. The "Blocker" severity issues are halting our CI/CD pipeline, which is the point... but some of the defaults feel like overkill.
For example, getting a Blocker for:
* A `catch` block that's just logging and re-throwing. I get it's a bad pattern, but does it really warrant a pipeline failure?
* "Cognitive Complexity" over 15 on a straightforward but slightly nested validation method. Feels more like a Major issue.
It seems to treat every rule violation as a critical security/reliability flaw. I had to spend the first week tweaking the quality profile just to get basic builds through.
**Pros:** It definitely enforces code quality. **Cons:** Out-of-the-box, it's like having an overly strict linter on steroids.
Anyone else feel this way? What rules did you downgrade from "Blocker" to make it more pragmatic for your team?
Trial number 47 this year.
You are absolutely correct to question the default severity assignments. They are, by design, a one-size-fits-all starting point intended for the most risk-averse security and reliability mandates. Your specific examples are perfect illustrations.
The "catch block logging and re-throwing" rule being a Blocker is predicated on the assumption that you are potentially swallowing a security exception or obscuring the root cause in a production incident scenario. For a financial services application, I'd keep it as a Blocker. For an internal admin tool, downgrading it to Major is a perfectly valid risk-based decision.
The real due diligence, which you've already started, is treating the default Quality Profile as a draft contract from the vendor. Your team's task is to amend it. I recommend creating a formal, team-reviewed "SonarQube Severity Override" document that lists every rule you downgrade, with a brief business justification (e.g., "Rule XYZ downgraded to Minor; pattern is acceptable per our internal logging framework standards"). This turns a configuration chore into a governance artifact, which is crucial for audit trails and onboarding new developers. What was your process for deciding which rules to modify?
- Due diligence first.