SONARJAVA-6532 Reclassify and take an action on rule 6541

[asya-vorobeva]

S6541: reduce noise by defining cap for issues to be raised. As a result we report maximum 30 issues per each project module.

It's experimental threshold; the further improvements can be done. Fo Peach projects I see that the number of issues decreased from 2135 to 2060. But it's not super representative, makes sense to monitor real customers' data.

---

Summary by Gitar

• Logic update:
  • Replaced hard-coded threshold with a percentage-based approach to limit reported BrainMethodCheck issues.
  • Added configurable thresholds for numberOfFoundIssuesThreshold, numberOfAdditionalIssuesThreshold, and issuesToReportPercentage.
• Rule status:
  • Promoted rule S6541 from beta to ready.
• Testing enhancements:
  • Introduced new test sources BrainMethodCheckSubsetCapped.java, BrainMethodCheckSubsetLarge.java, and BrainMethodCheckSubsetSmall.java.
  • Added comprehensive unit tests in BrainMethodCheckTest.java to verify threshold logic and capping behavior.

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-6532

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Refines BrainMethodCheck reporting logic by implementing a percentage-based threshold system and increasing the division factor to 15, successfully resolving sharp reporting cliffs and zero-issue rounding errors.

✅ 2 resolved

✅ Edge Case: Sharp cliff: crossing found-issues threshold drops reports drastically

📄 java-checks/src/main/java/org/sonar/java/checks/design/BrainMethodCheck.java:118-123
With the defaults (numberOfFoundIssuesThreshold=10, issuesToReportPercentage=10, numberOfIssuesPerModuleThreshold=50), a module with exactly 10 brain methods reports all 10 (the guard is > numberOfFoundIssuesThreshold), but a module with 11 reports only min(11*10/100, 50) = 1. So going from 10 to 11 detected issues drops the reported count from 10 to 1. This discontinuity is likely surprising for users and reviewers: a codebase that gets slightly worse suddenly surfaces far fewer issues. Consider making the transition continuous, e.g. report max(numberOfFoundIssuesThreshold, percentage-based-count) so the reported count never drops below what would be reported at the threshold boundary.

✅ Edge Case: Percentage rounding can report 0 issues while issues exist

📄 java-checks/src/main/java/org/sonar/java/checks/design/BrainMethodCheck.java:118-121
numberOfIssuesToReport = Math.min((numberOfIssuesToReport * issuesToReportPercentage) / 100, numberOfIssuesPerModuleThreshold) uses integer division. When size * percentage < 100, the result truncates to 0, so no issue is reported at all even though several brain methods were found. This cannot happen with the defaults (min size to enter the branch is 11 → 11*10/100 = 1), but it does occur with the configurations exercised in the new tests: with numberOfFoundIssuesThreshold=5 and percentage=10, a module with 6–9 found issues reports 0. If such configurations are supported, consider clamping to a minimum of 1 (e.g. Math.max(1, ...)) so that when the check enters the noise-reduction branch it still reports at least the most complex method.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube