Rules, Rule Types, Severities, Quality Profiles, and Customization: Configuration, Design Patterns, and Trade-Offs

1. Decision table

2. Inheritance is an upgrade strategy

A child inherits parent rule activation/deactivation and parameter changes unless a rule is overridden. This is why extending Sonar way usually scales better than copying it: new analyzer rules and deprecation changes can flow into the child. The cost is review discipline after upgrades. A growing overridden-rule list is effectively a growing policy fork.

Current Community Build also has an instance-level control over whether inherited active rules may be deactivated in a child. Record that administrative setting before relying on child deactivation as a policy mechanism; do not assume every instance permits it.

3. Avoid profile sprawl

Quality profiles are language-specific, so variants are legitimate when technical requirements truly differ. Keep the hierarchy small: Sonar way → organization guardrails → rare domain-specific children. Every extra profile needs an owner, purpose, associated-project inventory, review cadence and retirement condition.

flowchart TD
SW[Python Sonar way] --> O[Org Python Guardrails]
O --> A[Payments Python]
O --> B[Data Python]
A --> P1[Payments projects]
B --> P2[Data projects]

4. Rule severity/impact is not external risk scoring

Profile-level severity or impact customization changes Sonar issue classification and may affect downstream gate conditions. It does not create CVSS, exploitability probability, financial-risk score or developer performance grade. Security Hotspots remain review-oriented because their actual vulnerability status is unknown before review.

5. Parameter change, rule deactivation, issue exception and gate change are different

Parameter override → rule still applies; threshold/behavior changes for the profile.
Rule deactivation → rule no longer checks matching code in that profile.
Issue exception   → one finding is accepted/false-positive; rule remains active.
Quality Gate edit → downstream pass/fail policy changes; active rules do not.

Choose the narrowest layer that expresses the real intent. Do not deactivate an organization-wide rule to handle one exceptional issue.

6. Analyzer and plugin rule provenance

The Rules page shows a repository identifier for the engine/analyzer contributing a rule. Commercial editions can add rules unavailable in Community Build; third-party plugins may add their own repositories. Treat plugin rule sets as executable server extensions with provenance, security, license, maintenance, compatibility and rollback implications. The mandatory course path installs no plugin.

7. Default profile versus explicit project association

Changing the language default can move policy for every project that relies on it implicitly. An explicit project association has a smaller blast radius and is the correct mechanism for experiments. Before a default change, inventory implicit default users and explicit exceptions; after it, verify which projects actually changed.

8. Product and edition boundaries

The mandatory path remains Community Build and local. Commercial SonarQube Server editions can expose additional rules or governance capabilities, and Data Center Edition changes deployment/availability topology rather than the basic profile mental model. SonarQube Cloud is a separate hosted product with organization/plan semantics and no self-managed server/plugin administration. Verify the current feature matrix before teaching an edition-specific rule or profile capability.

Also separate configuration owners: scanner/build parameters select analysis inputs, server/profile configuration selects rule policy, and project issues/gates are results. Do not move a scanner problem into profile policy or a profile problem into database/search state.

9. Minimum policy change record

10. Challenge: consolidate seven near-duplicate Python profiles

Seven profiles differ only by S3776 thresholds and several have no owner. A strong consolidation plan first inventories active project associations and issue deltas, chooses one organization parent, retains only evidence-backed domain variants, migrates projects deliberately, exports backups and retires old profiles only after proving no remaining association.

Knowledge check

Official references and version notes

• Community Build — SonarQube rules — repositories, statuses, rule categories, custom/template rules and mode-dependent severity semantics.
• Community Build — Instance mode overview, including MQR Mode and Standard Experience.
• Community Build — Understanding quality profiles — built-in/default profiles, inheritance, overrides and project association.
• Community Build — Creating a quality profile — Extend, Copy, blank creation and import/export.
• Community Build — Editing a custom quality profile — activate/deactivate rules, customize parameters and Revert to Parent Definition.
• Community Build — Associating a quality profile with projects.
• Sonar Rules — Python S3776 — Cognitive Complexity rule used in the controlled parameter experiment.
• SonarQube releases — current Community Build and Server release identities.