Sonar is destroying my job and it's driving me to despair

First of all, I understand that Sonar is a well intentioned product.

It’s right most of the time. Unfortunately coding is, of course, complex and it’s challenging for a product like Sonar to keep pace with the fast changing syntax of newer languages.

I’m an experienced Developer and Team Lead, currently coding in Kotlin with Coroutines. I’ve also worked with Java, C++, C, Objective-C and Swift. We can all learn more, but I’ve been around the block and know a few things about what code quality looks like and how to make pragmatic decisions around it.

Our ‘default’ Sonar setup is currently making me ‘butcher’ my Kotlin code to comply with it’s rules and, as you may tell, it’s really upsetting.

You may say “The rules can be customised”, or “Allow an exception”. You need to understand that is not a simple option for many of your users. In my case, I have a superior who administers Sonar and is, let’s say, completely committed to it. For any ‘exception granted’ we would have to book time with them days in advance then white-board the reason why Sonar is wrong, or produce a sample program - who has got time for that with tight deadlines?

Please rethink your UX with the realisation that there are probably many professional and experienced software engineers out there who - far from appreciating your product, actually feel genuinely oppressed by it: like victims of a cold unfeeling system with no ‘right to reply’. Unable to merge deadline code until every point is addressed, for better or worse. It’s a terrible helpless feeling.

A couple of Kotlin examples:

  • Inability to define a single suspending function interface. Sonar tells me to make it a fun interface, then tells me fun interfaces can’t have suspending functions. I should make this a functional type instead? Completely inconsistent with the rest of the code and removes the opportunity to provide information though labelling the function.

  • Sonar doesn’t respect import aliasing. Let’s say I have Domain and Service models for some entities. I have ‘Person’ defined in domain and service packages. In one of those packages, I want to write a mapper extension. I use import aliasing to disambiguate each ‘Person’ as DomainPerson and ServicePerson. This is an informative convention, but Sonar doesn’t allow it: import service.Person as ServicePerson is considered redundant. I could then use a private typealias ServicePerson = Person` but this isn’t the same.

These are just two examples, I could find more.

Can you do something with your product to give users more of a ‘right to reply’ and re-empower them?
There will be creative ways to achieve this without undermining Sonar’s purpose. Just some ideas:

  • Allow a user role where rules can be overridden but the admin gets informed and can remove the override at a later time.
  • A mode where an override can be granted by 3-4 other users all agreeing, who aren’t admins.
  • Button to fast-access (lazily create) a community thread regarding a certain rule, to report a problem with it, so you know your difficulty is being heard at least by Sonar, if not within your organisation.

Thank you for listening to my part rant, part suggestions. This is sincere.


Hey there.

Thanks for the feedback. It’s essential in our quest to ensure developers not only find value in our products but also enjoy and feel empowered by the experience.

If you disagree with a rule implementation, I encourage you to post the details in the category titled Report a False-Positive/False-Negative, for which we have a post detailing what is required to report (code sample, product versions, rule IDs…). Our teams are very reactive and enjoy engaging in these discussions.

There is an Administer Issue permission that in most organizations would be granted to Team leaders or experienced developers (like yourself) to be able to mark issues as False-Positive/Won’t Fix.

Somebody else (like your superior) has at least two options (maybe more) to discover these exceptions:

  • Using the Issues tab of a project (or the SonarQube instance overall) to filter for issues that are marked as False-Positive / Won’t Fix if they want to do some kind of global review.
  • Configure a project-level e-mail notification for Issues resolved as false positive or won’t fix

And, to be honest, Chris, if you have a superior that trusts in Sonar 100% and trusts you and your fellow developers very little (unwilling to delegate permissions, decision making)… I think that’s the root of your problem and not one that can be fixed with product changes. We create a new user role? Enable some kind of consensus-driven issue status? Your superior could just decide not to grant it.

Happy to continue discussing this.


Hi @Chris_Hatton, we are looking into something similar to this at the moment. If you would be willing, I’d love to have a short call to talk to you about your suggestion.

if you have a superior that trusts in Sonar 100% and trusts you and your fellow developers very little (unwilling to delegate permissions, decision making)… I think that’s the root of your problem

You make a fair point that anyone who uses a tool and does not understand is part of the problem. However, if the tool could be easier to understand, that could go a long way to addressing that issue.

Respectfully, the root of the problem is that SonarQube is not clear to everyone who uses it. Specifically, it offers little towards gauging what is important and and what is not. Programmers have been engaged with a tug of war with management since the dawn of the digital era. Managers, who don’t understand coding well enough to police it, are now offered Sonarqube as a policing tool. They are given a bat to hit programmers over the head. This has an easy metric for determining perfections – 0 issues found. It’s a managers dream – a computer that sums up everything you need to know in one number. If you give someone a bat, they’re going to use it to hit things. It’s pretty simple.

The number of issues found in your project is similar to likes on social media – it’s a badge of honor to show off to all your manager friends. I have a coding library that’s tens of thousands of lines. Military Standard data types are defined by two numbers, so my (Java) class names end with something like “_1234_567” Like a good programmer, my fields and getters follow the same naming pattern.
This violates S101, S116, S100, S101 for a total of 4.7k hits. This has caused everyone to freak out.

The OP point is well taken, that if I had an opportunity to add some structured comments to that report before a manager read it, the sky would not be falling. Now I am having trouble explaining in meeting after meeting, “we violated 4 MINOR rules on purpose. So if we ignore those rules like we’re supposed to, the 4,700 hits go away.” To which they respond, “You want us to cover up 4,700 hits?”

Clearly, it’s a major problem that they don’t understand a minor sonarqube finding “may slightly impact developer productivity” and it may also not affect quality.

So thanks to Sonarqube, I am going to have to make my code unreadable to a human in order to please management, which means INTENTIONALLY creating a mountain of technical debt. But that’s okay, because Sonarqube doesn’t count it.

Sonarqube exacerbates the problem of communication with management; it does not help it. The problem is how the information is presented. As OP pointed out, Programmers don’t have an opportunity to respond proactively to the issues. It’s fair to blame managers, it also fair to blame the bad information they are given to make decisions. For example, your issue count could be broken down into “must address” and “not urgent” or the like. It could further have something like, “4,712 issues have open discussions, here is a link.” The idea that a single number could sum up technical debt is simply dangerous. It encourages people to NOT investigate and learn more. It encourages people to not listen.

“Dude, look, it’s really simple, your project has 4,700 sonarqube findings, everyone else has less than 100. This is a job performance problem.” – Overheard in a meeting

Finally, I have a question. Are there articles posted by Sonarsource telling managers how to interpret sonarqube results properly? I’ve been scouring the web for “how to handle minor sonarqube issues best practice” and found nothing useful to my case. I’d welcome knowledge if anyone has any.


Hey there @Jeremy_Cox.

Thanks for the super valuable feedback (that we’ve been discussing a lot internally). I want to provide a few preliminary notes.

  • We’re conscious of the fact that Sonar can be misused, and we’ve made some efforts to minimize how easy that is. We once had a feature (meant to “gamify” fixing issues and not introducing new ones) which… you guessed it, resulted in some managers using it to measure individual performance. Some organizations loved this feature! We removed it because it absolutely didn’t align with our values.

  • A big shift is going to come to our products soon (this year) that will shift focus on raising findings about facts about the code (this is not a coding practice that aligns with our organization’s practices), rather than issues with a hypothesized impact (“this may slightly impact developer productivity”). This repositioning might also make it easier to explain why you want to ignore a rule. T

  • As part of this shift we are also looking at how to make sure Clean Code (and Clean as You Code) is easy to understand by governance stakeholders and de-emphasize issue count. Yes, there will be product changes that have to happen as well as education/positioning that has to change (no silver bullets, only lots of reuglar ones)

I don’t think we have anything regarding this. It’s a valid point I’ll pass on.

Please don’t hesitate to keep giving us honest feedback as things progress, or if you’ve thought of any other points you want to share. Feedback is a gift. :gift: