I’m using sonar 7.7 enterprise. I want to annotate a piece of javascript code to ignore a particular squid on the next line, just like I do in java with something like SuppressWarnings(“squid:S00112”)
What is the equivalent annotation syntax for javascript? I’m aware of //NOSONAR but that ignores everything on that line which is not what I’m looking for. I want to ignore a specific violation on a specific line. I’ve also read the “Narrowing the focus” portion of the sonar doc but that’s all server side stuff which prevents a code reviewer from spotting a warning suppression and questioning it.
If the feature is not there for javascript, why is that the case? Is another recommended pattern to achieve this with a different mechanism?
Hello Damon, I am Dmitry and I am happy to help you here.
In order to suppress the specific issue - you can also mark this issue as False Positive through the issues interface. This will disable the warning in the current branch.
From a developer point of view, however, I would be interested to know the cause of your decision to disable specific rule. Any feedback you can provide will help us improving the precision of the rule.
Moreover, I advice you to upgrade to LTS 7.9.x version if this is appropriate for you.
Thanks Dmitry. I’m on a team that deploys sonar and we’re trying to provide guidelines for when it’s appropriate to ignore a violations. We’re trying to apply the same quality profiles and quality gates across the company and avoid going down the road of customizing them, as to provide unified quality practices as engineers move between teams. That said it means when we change rules we do so deliberately as an organization. I’ve used sonar with java before. My past practice on a java product was to
Prefer fixing violations first
Ignoring specific violations on a method in rare cases where we knew we wouldn’t fix it. I’m coming to realize that @Suppress warnings is only available for java.
Even rarer cases may warrant annotating the suppression of that rule at the class level
The above seemed like a reasonable approach for java but I don’t see the the same approach is feasible for javascript. From what you’re suggesting, if I started down the path of doing this on the server side instead of annotating thecode, these violation false positives on a branch wouldn’t necessarily carry through once merged to master. IS that true or would you not need to suppress them again once merged?
You can try to mark it as FP on your main branch - then the status of the issue should be persisted on the new branches forked from that one (not existing ones). Please, also note that those branches would have their own issue lifecycle and will no longer inherit issue status from the main branch in subsequent analysis.