Python static analysis tools, such as flake8 or pylint support the convention of adding a # noqa: <rule> or # pylint: <rule> comment line to disregard a rule on a specific line. I’d love to see this same kind of thing come to Sonar Qube or Sonar Lint. Ideally, I’d prefer for it to use the pylint or noqa on its own rather than defining a new one.
This would give me, as the developer, the ability to add exceptions for specific rules on a line or file basis without having to change the sonar-project file or the project config on the server.
Documentation of the existing standards:
1 Like
BTW, while I give Python specific examples here (and it would be nice to support existing standards here), I think having something like this for each language would be a good thing.
Maybe for C#, something like:
string s = "";
try
{
s = File.ReadAllText(fileName);
}
catch (Exception e)
{
throw; // nosonar: S2737
}
1 Like
Hello @Josh_Schneider and thanks for posting this suggestion, we’ve made a note of it.
What is already possible today in SonarQube is to:
In both cases, when you use SonarLint in connected mode, those settings will be automatically synchronized from SonarQube to your IDE. Please note that such mechanism is totally language-agnostic and you can use it for any of your projects.
To better understand the context of your suggest, it would be very interesting for us to understand ( especially in case you already tried the above) why your preference goes for using comments in the source code; is it because you use additional tools / linters and you are seeking of a more “standard” why to suppress detections?
@Josh_Schneider, I forgot to mention that, as an additional workaround you can specify a #NOSONAR comment for the line where you want to mute issues:
Please note that with this workaround, you cannot specify a specific rule - all issues on that line will be mute.
And still, I would be interested to understand which approach you prefer between this one and those I described above, and why 
While SonarQube runs static analysis, the process itself can indirectly cause problems when running code or analyzing failures.
• Obscured Terminal Logs: The voluminous output from a comprehensive SonarQube analysis can often obscure critical terminal logs or compiler/test output. This makes it difficult for a developer to quickly pinpoint the actual cause of a build or test failure, forcing time-consuming manual log searches.
• Introducing Runtime Bugs: When developers rush to address a high-priority Sonar bug or vulnerability report, they may implement a functionally incorrect “fix.” This hasty correction adheres to the Sonar rule but breaks the code’s intended business logic, directly leading to new runtime issues in the deployed application.
Just to clarify — SonarLint or SonarQube should recognize that using # noqa is sometimes necessary, especially when adding inline comments in restricted code environments isn’t possible. However, deactivating the rule entirely isn’t the right solution — similar to how Pylint handles selective suppression for specific lines.
