Hi Jeff, and welcome to our community forum.
Your concern is totally valid. In the past we tried to “solve” this issue by trying to cover all rules provided by other popular linters, so that our answer was simply “only use SonarSource analyzer”. This strategy was not sustainable. Keeping our analyzer up to date with other linters is very hard. Also sometimes they make some decisions we disagree with. For example, some linters have a very strong focus on code formatting rules, with a lot of parameters, while we try to only cover “standards” code formatting.
If you use SonarLint with other linters, you may:
- have third party linter reporting issues that SonarLint can’t or don’t want to report
- have SonarLint reporting issues that no third party linter would find (at least we hope so )
- have the same issues reported both by SonarLint and third party linter
You can mitigate 3. by playing with ruleset configuration (disabling the rule on SonarLint or third party linter), but this can be fastidious, and also risky. A rule may look to produce the same issues by SonarLint and third party linter (case 3.), so you would be tempted to disable it on one side. But due to implementation differences, there are possibly some specific cases where you would have ended up in case 1. or 2.
Note that our Kotlin analyzer is currently very limited, with very few rules. So I suggest you keep using third party linter in your IDE for the time being.
Last comment: if you intend to keep SonarLint only, but you really miss some rules from a third party linter, don’t hesitate to post in the rule suggestion category.