In my current effort to provide a plugin for SonarQube allowing to scan Rust code and import Clippy lints,
I am requesting some feedback about best way to reconcile the Lint levels definition with SonarQube requirements for what it defines as "Issues"
With SonarQube, Issues have two dimensions :
There are three types of issues:
- Bug – A coding error that will break your code and needs to be fixed immediately.
- Vulnerability – A point in your code that's open to attack.
- Codesmell – A maintainability issue that makes your code confusing and difficult to maintain.
Each issue has one of five severities:
Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed.
Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed.
Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ...
Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ...
Neither a bug nor a quality flaw, just a finding.
On the other hand there are 4 Lints levels :
Would a systematic mapping from Lint levels to SonarQube issues make sense in your opinion, e.g
"all Clippy lints with level deny should be imported as SonarQube "Code Smells" with Severity "CRITICAL" etc... ?
If so would you have suggestion about how to map ?
Should the Clippy Lint groups (Correctness Restriction Style Deprecated Pedantic Complexity Perf Cargo Nursery) be (also) considered to define such mapping into SonarQube in your opinion ?
Thanks for your feedback