Issues tab: add message filter

SQ gives a message with each rule, but for some rules, the message will be “crafted” to the specific code. For instance, rule java:S2159 in general says, “Silly equality checks should not be made” but specific instances might have a message like “…comparisons against null always return false…” or “…comparisons between unrelated types always return false…” The first message appears for something like “if (foo.equals(null))…” which is clearly more dangerous than the other cases (because those can lead to NullPointerException’s).

It would be nice to separate these different sub-cases. I can use the web_api for this, by piping through, say, … | ?{$_.message -match ‘null’} in PowerShell. But having a regex-based, or at least substring-based, filter in the web portal would make it easier to have a developer look at, say, the null-equality checks only. (Also having this as another parameter in the web_api would be nice, especially when encountering the 10K limit.)

(Also see TSQL plug-in: filtering message specific issues) – IDK if this is what the OP was getting at but it sounds similar.)


You’ve asked for an issue search filter to solve your problem, but I think it’s worth asking about splitting the rule instead / in addition. Do you have an opinion on that? And if so, what language are we talking about?


Well, I was specifically talking about java:S2159 in this case. But this rule itself has 7 different subcases, according to the description. IDK if each one corresponds to a different message being generated (I only see two message formats, but that could be just because I’m only hitting two subcases). But I might want to do the same thing for many other rules that also vary the message according to the details of the code doing the violating. So there could be many different subcases per rule, so the 600+ Java rules could easily turn into several thousand. (Not even counting the rules that put the name of a variable in the message field.)

So I think a regex- or substring-based filter on the message field would be more feasible in the general case.

1 Like