Tuning
Stop a rule that is drowning everything else
On a real estate the top ten rules by count usually produce close to half of all findings. That is not a sign of a badly written rule; it is a sign that the rule is reporting a pattern rather than a defect. There are three instruments and they are deliberately different.
What to do
-
Find out which rules are actually responsible. The Findings page groups by rule, and the count next to each is the honest answer to whether tuning is worth the hour.
-
If the rule is right but graded too high for your context, use Severity rather than muting it. A regrade keeps the findings and moves them down the list.
-
If the rule is reporting a pattern nobody is going to act on, use a rule mute. That sets aside every finding that rule will ever produce, so it needs a second administrator to agree before it takes effect.
-
If it is only wrong in some places, write an exclusion scoped to those paths instead. Vendored directories, generated code and test fixtures are the usual three.
-
Whichever you choose, put the reason in. In six months the question will be why, and the count will not answer it.
Worth knowing
A rule mute is the widest instrument in the product. It hides findings you have not seen yet, estate wide, with no expiry. That is why it needs two people.
Other guides
Install the editor plugin on Windows
VS Code, Cursor, IntelliJ and Eclipse, from your own server rather than a marketplace.
ReadInstall the editor plugin on macOS or Linux
The same three files, with the paths and the package manager that platform uses.
ReadExclude one credential everywhere it appears
The same test key committed to nine repositories, set aside once.
Read