Do you use SonarLint?

SonarLint is a free IDE-plugin to help you write clean code from the first keystroke by raising new issues as you type. We’re wondering:

  • Do you use it?
  • If so, do you use it in connected mode with SonarQube or SonarCloud and if not, why?
  • Which came first for you: SonarLint or SonarQube/SonarCloud?

I use SonarLint in Visual Studio, with a connection to SonarQube. We started using SonarQube before I started using SonarLint. A big benefit of having the connection is that the rules are synced with the Quality Profile that is managed on SonarQube.

I tried to use individual project tokens for the different projects, that mostly live in different git repositories. But I ended up using a single global token instead, which ended up being less to manage than a number of tokens north of 5.


My team uses SonarLint with IntelliJ. It is connected to SonarCloud. We started with SonarCloud first, then added SonarLint.


It depends on the IDE and language:

  • for Java with Eclipse I use SonarLint, but not in connected mode
  • for all other languages (C#, Typescript, F#, Yaml, Powershell, …) either Visual Studio or Visual Studio Code I’m using. There I don’t use SonarLint at all.

I tried some years ago the connected mode and where unhappy with its configuration and upgrading of the rulesets in the repositories. Therefore we don’t use the connected mode.

1 Like

We use SonarLint and we want to enforce the use of the solution. Unfortunately, you do not have insight to who is using SonarLint and who is not. I have submitted an SonarQube enhancement to capture who is connecting to SonarQube via the IDE SonarLint plugin to help us identify who is not using it.

HI all,

Thanks for sharing where you are with SonarLint.

@milbrandt I wanted to point out that in the last couple years we’ve done a lot, I mean a lot of work on the UX of connected mode and its benefits. You might want to give it another try.

And I’m curious why you would use it in one IDE / for one language but not the others…? You tried and just didn’t see the benefit?


Hi @ganncamp

our SonarQube instance is running in the company network and is not exposed to the internet.

In Java we use the SonarWay ruleset without modifications. These are only two smaller repos. Thus we can use the default ruleset without downloading and only few people are working on it.

For C# we made a copy of the SonarWay ruleset and modified it (copied to switch off some rules, which we couldn’t do in another way). Here we would need to use a copy of the ruleset.

On C# and Typescript there are more people involved, for Typescript also an external contractor. So the benefit and effort needed was not sufficent, the PRs are analyzed on the build system anyway.

1 Like

from my observation, the SonarQube current release does not provide insight to who is using the SonarLint and connecting to the SonarQube server. Therefore we do not know who has adopted SonarLint within the developer’s IDE

1 Like

We use SonarLint linked to SonarCloud with VSCode and InteliJ based IDEs, but only for our Python code since it lacks Go support. Because of that most of our developers do not install it.

Something I would love to get from SonarLint is a mode to focus on changed lines, just like the reports for PRs are focused on changed code only.

As far as history:

  • used SonarQube first, maybe 10y ago.
  • switched to SonarCloud maybe 5y ago.
  • started using SonarLint about 3-4y ago.

We want to use SonarLint more, but adding more languages such as GoLang will go a long ways to improve adoption. We really like how ‘snappy’ it is compared to other listing solutions.


Hi all,

Thanks for the detail @milbrandt! It’s helpful.

@morjo02 thanks for responding. Do you use SonarLint? If you had insight into who is/isn’t using SonarLint, what would you do with it?

@sodul I believe we’re turning our attention to the only-changed-lines topic soon. And good to know about Go &etc. I’ll nudge the PM.



Hi Ann, if we had insights to the use of SonarLint then we can engage each of the developers to promote, adopt and adhere to our engineering SDLC practices.

1 Like

:heart_eyes: Exactly what I hoped you’d say. I’ll make sure the PMs see this.


1 Like

Hi @morjo02,

Thanks for your insight.
We are considering helping administrators to monitor the global adoption of SonarLint in the organization so that admins can know if they need to take actions to promote the use of SonarLint .
We have a portal card where all users can share their needs. If you leave your email on the card, you will receive a notification if we move forward with the topic.

Going further with your suggestion, giving the possibility to track the individual use of SonarLint can be perceived as quite intrusive. I wonder if this is something all organizations would be comfortable with.


1 Like

Hi Christophe, Thank you for the update. I am aware of the portal card as I was the individual that initiated this idea. I look forward to this new SonarQube capability and continue to drive the adoption. We consider SonarLint as the Spelling / Grammar Checker for Code :sunglasses: :nerd_face:

1 Like

We do not generally recommend SonarLint in our organisation for a number of reasons:

  • For a large mature codebase with a lot of existing issues, you can’t really see forest for the trees - you can’t focus on new issues because the IDE (Visual Studio in most cases, C# projects) shows all issues
  • It is hard to configure in a mono repo
  • It does not respect all the SonarQube settings (at least not in .NET)
  • The scanner versions it uses can be different to the ones in SonarQube itself so you can get different results locally than you get when the “real” analysis runs in a CI environment
  • It comes with it’s own bugs :slight_smile:
  • It does not (or did not a few months back) report all of the issues that SonarQube would report - notably lacking in security hotspots.

We have been hit by all of the above at various points, particularly on our large, mature, mono-repo, C# codebase. I think the biggest issue is seeing all the many thousands of existing issues all the time which nobody can reasonably sift through.

Unfortunately the above makes up the majority of our codebase and hits most of our developers.

For newer, smaller, non-mono repo c# codebases and other smaller/less mature language repos, engineers have had some success using it with Visual Studio Code and I think with PyCharm too.
We do have to caveat their usage with a disclaimer that the “real” analysis in the CI build is the only one you can really trust and that you might get different/missing results locally…but most of the time it is probably going to be okay for them.

For any use, it has to be connected mode because we customise the rules - once you go that route, there is very little point in using it unconnected since you are, by definition, going to get different results


Thanks for this feedback @tbutler! We have indeed prioritized some of those pain points - I am pretty sure you are aware :slight_smile: but I am sharing here as it can benefit other users in this forum.
We are working to bring Security Hotspots support in SonarLint (it is actually already available for VSCode and IntelliJ) and we’re considering new features to help developers focus on new/recent issues when they code and when they are about to commit.

I would like to ask you some more information about this topic:

  • It is hard to configure in a mono repo

Is it purely related to “seeing all the many thousands of existing issues” or are there other reasons that make SonarLint not effective specifically with monorepos?

Hi @Marco_Comi

Visual Studio (not Code) is the one where we would benefit from hotspots support the most :}

re: mono repo - the number of existing issues is definitely a big problem but it is also about having to add conditionals in csproj files to ensure that shared code is only analysed in specific solutions. If we have 1 project shared, as a project reference and not a binary, between 20 solutions, we don’t want to see the same issues appear in all 20 solutions.

It’s a while since we looked at this but IIRC there was a lot of faffing about/manual adjustments when a solution was added in connected mode to undo some of the automatic changes and make sure the right ruleset was referenced for the shared code as well as conditionals on rulesets/additional file inclusions.

Now multiply by > 50 shared projects across about 30 solutions and you can see how this might be painful :wink:


Hi @sodul,
FYI we’ve just released the support of Go analysis in GoLand :wink:

Something I would love to get from SonarLint is a mode to focus on changed lines, just like the reports for PRs are focused on changed code only.

We’re definitely looking at ways to focus on recently changed code, you can follow this roadmap card (if you’re not doing it already).