Maintaining a custom ruleset is quite a bit of work. And sometimes we could miss something by a disabled option... But I think we could make a PR fail only if new severe issues are introduced, ignoring the others (i.e. warn is informational)
By the way, there are 100s more rules, e.g. no dot-chaining, only one return per method, etc., which I wouldnt want to enable either. Am So., 5. Jan. 2025 um 20:45 Uhr schrieb Elliotte Rusty Harold <elh...@ibiblio.org>: > > On Sun, Jan 5, 2025 at 7:28 PM Benjamin Marwell <bmarw...@apache.org> wrote: > > > > Not sure about Elliotes NPEs. The ones I checked were valid, e.g.: > > https://sonarcloud.io/project/issues?open=AZQn8ht1KAwsFelognsS&id=support-and-care_maven > > > > That does look like a real bug, better than any of the ones I > initially noticed, but I also notice that several bugs before and > after that are essentially noise: things we don't need to fix and > likely shouldn't fix. The ratio of true bugs to non-bugs is way too > low to make SonarQube interesting. I certainly wouldn't want to run it > on every PR until there's a way to eliminate 99.9%+ of the noise. > Otherwise it will simply be ignored. > > I suspect misaligned incentives are in play. Tools like this tend to > market by how many bugs they can find, so they try really hard to > report everything they can think of, even things that aren't bugs, > even things that make code actively worse. > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
