The main options for blocking reporting of an issue in SQ are either to mark the issue itself, or annotate the code, either with NOSONAR or @suppresswarnings(). We normally use the former but would like to use the latter in some cases.
For instance, the null pointer rule java:S2259 often has false positives. In many cases (at least for US) this is because our code has convoluted logic where we know an NPE can’t occur at a certain place, but only because we have high-level knowledge of the application that is beyond SQ’s ken. We could mark that instance FP, but there’s the risk that a dev might make a subtle change that then violates the assumptions and makes the NPE possible.
For such cases, we’d prefer an explicit annotation in the actual code. Something that says, in effect: “WE TOOK THE GUARD RAIL OFF HERE, SO IF YOU CHANGE THIS METHOD, YOU’D BETTER MAKE SURE YOU DIDN’T INTRODUCE AN NPE HERE, OR WE’LL HANG AN ALBATROSS AROUND YOUR NECK!”
We could tag the specific line of code with NOSONAR, but that suppresses ALL issues on that line. @Suppresswarnings gives rule-specificity, but only at the granularity of a method (if I’m reading current documentation correctly). What I’d like is to combine the two, something like //NOSONAR(“java:S2259”) or make @Suppresswarnings only apply to one region of code.
makes me think you want/expect the previously-ignored-in-code warning to be re-raised when the code is changed…?
That’s possible with the Won’t Fix/False Positive mechanism implemented server-side; when the code changes the issue can be re-raised. But with an in-code notation of “these are not the droids you were looking for” … that code will always be “not the droids” regardless of whether it changes or not.
Well it gets tricky with S2259, the NPE check, because there can be large distances involved. We might have something like this pseudocode:
X = null;
do stuff
if (Y) { X = a proper object }
do a bunch of stuff
if (Z) { // Z only true if Y was true before
foo(X.bar)
SQ can’t prove there doesn’t exist a path from 1 to 6 and therefore flags it. (Sometimes the logic can be quite convoluted. For instance, Y and Z could be identical method calls, and we have high-level knowledge that the two calls will return the same value, but SQ doesn’t know that.)
If we mark it FP, what happens if someone goes in to part 4 and breaks the connection between Z and Y? Is changing any line of code in the flow between 1 and 6 sufficient to tickle SQ so it ignores the FP setting and calls the NPE a new issue?
Actually… once you finally upgrade to a supported version I think you’ll find the detection has gotten a lot better and this is probably possible. I’m not going to swear we’ve worked on the NPE rule yet, but if we haven’t it’s on the list.
Yeah yeah… But we’re getting side-tracked. My OP said “for instance” so the NPE was just one instance where I could use what I’m asking for – being able to make //NOSONAR apply to just one or some rules.
I think you’ll find the detection has gotten a lot better and this is probably possible. I’m not going to swear we’ve worked on the NPE rule yet, but if we haven’t it’s on the list.
But we’re getting side-tracked. My OP said “for instance” so the NPE was just one instance where I could use what I’m asking for – being able to make //NOSONAR apply to just one or some rules.