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

> 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?

This superior (sic) is what a negative productivity employee looks like.

We frequently have the issue of, upon refactoring code in such a way that involves moving it and its tests to a new file, Sonar will take away our previous "credit" for code coverage percentage, dropping our project below the threshold and failing.

The only workaround I've found is to create a new function, fill it full of many useless no-op lines, and write a test for that function, just to bump the percentages back up. This is often harder than it sounds, because the linter will block many types of useless no-op code. We then remove the code as part of another ticket.

The root issue is the superior not having a clue. Sonar in this case, is sadly enabling this type of superior to be even more harmful, not to the developers only, but to the actual business of the company.

And Sonar is far from being alone in this. JIRA is the most glaring example I can think of. Growing companies implement cargo-culted tools without understanding the needs and requirements, and let themselves drift into templates or "best practices" that are not relevant or beneficial to their own operations as-is, resulting in a sum of frustrations, whose impact on the work and the teams they acknowledge only way too late.

The care you need to inject not only in your tools, but how they are apprehended by both your customers and their primary users (which may have very different, if not opposed, perspectives on how/why to use it), from pricing, to documentation, to use-cases...

This is especially very complex when your tool answers to a regulation requirement, because it's very often received as a constraining/oppressing "solution", rather than an enabling one: it may be confortable to you as a seller, and confortable to your customer, but it may also be a counter-sale point to your (customer's) users that will impact future consideration when they become purchasing agents themselves.

>SonarQube (formerly Sonar) is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs and code smells on 29 programming languages.

https://en.wikipedia.org/wiki/SonarQube

No matter the industry, it sucks to have someone managing by dashboard. In classic post modernism, the signifier replaces the signified. If anything, it’s a great signal to the employee that it’s time to start looking elsewhere.

Sonar tries hard to have an authority of a compiler, while having the resources of a linter.

I am not saying it's snake oil, but honestly how i ve seen ut being used, it's not that far

Sonar doesn't seem to really work in my limited experience. It adds a lot of of time to builds, at least in the cases I've seen, while there are alternate linters or code quality tools capable of doing the same at a fraction of the time. Build times and development speed matter!... They matter a lot. You need a quick feedback loop.

This sounds truly hellish, like being controlled by a stupid robot straight out of Kafka's "The Trial." They should allow special one off exception that are documented with a comment, similar to how you can disable Ruff warnings in python code for a single like

  # noqa: F401

I'm not sure how much value sonar adds where I work (dotnet). It enormously affects build times, and I've yet to experience a single true positive in 2 years (apart from the code coverage dashboard). The amount of MRR you can generate by vaguely being related to mitigating vulnerabilities is incredible.

At my work you can mark any issue with "won't fix". The issues are right pretty often though.

Any sort of static analysis/linting tools will occasionally make bad/unhelpful/stupid suggestions, some moreso than others. At any place where I've had to use such tools, I've always had the ability to either tweak the settings, or have a conversation with the people who decide them and make appropriate changes. In this case, it sounds like bad culture and/or bad colleagues are driving this person to despair, and not Sonar as per se.

Well, we built Trunk Check to address some of these issues. Maybe it'll suit your org better.

- We support hold-the-line: we only lint on diffs so you can refactor as you go. Gradual adoption. - Use existing configs: use standard OSS tools you know. Trunk Check runs them with standardized rules and output format. - Better config management: define config within each repo and still let you do shared configs across the org by defining your own plugin repos. - Better ignores: You can define line and project level ignores in the repo - Still have nightly reporting: We do let you run nightly on all changes and report them to track code base health and catch high-risk vulnerabilities and issues. There's a web app to view everything.

Try it and let me know how it goes. https://docs.trunk.io/check/usage

I sympathize with the OP. Having said that, I’ve rolled out SonarCloud to two different companies and I would not hesitate to roll it out to a third if given the opportunity.

Initially, people always come out of the woodwork insisting that the gate requirements must be hard blockers and that we can just hand wave away the issues OP listed by tweaking the project rules. I always fight them, insisting that teams should be the owners and to gain quick adoption it should just be considered as another tool for PR reviewers. Eventually, people back off and come to accept that Sonar can be really helpful, but at the end of the day the developers should be trusted to make the right call for the situation. It’s not like we aren’t still requiring code reviews. I feel for OP, but it’s not Sonar’s fault the tool is being used for evil instead of good.

This last time I implemented SonarCloud, I took an anonymous survey to get peoples opinion. For the most part people liked the feedback Sonar provided. More junior engineers and more senior engineers liked it the most- midlevel engineers not so much. The junior liked getting quick feedback prior to asking for code reviews. The more senior engineers - who spend a lot of their time doing PR reviews - liked that it handled more of the generic stuff so that they could focus more on the business logic or other aspects of the PR. It’s just another tool in the toolbox.

I saw a case where Sonar analysis was being requested by a government agency where software was built by consultants. From the government agency's point of view it made some sense to ensure that the code delivered by the consultants wasn't full-on spaghetti.

However, I saw it causing similar turd polishing behaviour: Sensible code needing to be changed because it exceeded some obstinate metric, any kind of code movement causing existing issues to appear as "new", false positives due to incomplete language feature support, etc.

Isn't the actual issue here the superior managing the sonar being a controlling jerk? Turning off the rules on sonar is easy, technically. The issue is social.

Sonarqube issues were the warning for the SOC-report powered issue scanners that have arrived more recently.

Are the defaults emphatic to the engineer or to the ruleset?

add (2023)?

We use sonar at work and this resonates so much with me.