SonarQube reduces our code quality through arbitrary nonsense rules, and it's inability to understand perfectly decent Kotlin code. Unfortunately we have a CTO who is completely enamoured with it. I hope someone from Sonar is reading this: You made my pleasurable Dev job a misery, and it may very well be the thing that makes me quit. Fuck your arrogant product. I honestly wouldn't mind it so much if your UX offered a way to discuss each warning and provide affected code snippets so you could argue your case and collaborate on the rule set. But no, you know my code base best right? Fuck you and and your ivory tower.

Proper ranting, good stuff!

isn't sonar qube simply a tool that automates gradle tasks? just relax your gradle tasks a bit to your liking. also lint and other rules are pretty standard for android apps of all scales, so it is by no means reducing your app quality but rather improving it. and the main problem is your CTO prioritising generic warnings from a 3rd party software over his own developer's experience.

@dotenvironment It's static analysis not Gradle automation. We can't override anything due to CTO being the only admin. Even Tech Lead isn't trusted. You're right about the CTO.

Love it.

Had screaming discussions with some devs about static code analysis.

Any sane static code analysis allows the definition of a ruleset.

Note that a ruleset is not adding annotations throughout the project - which is bad for many reasons.

Ruleset is e.g. an XML or similar definition file that defines what rules should be applied.

https://docs.sonarqube.org/latest/...

In Sonarqube it's called "Quality profiles".

IMHO the sonarqube defaults don't suck, though I've never dealt with Kotlin and Sonarqube before.

But just taking the default rules / default profile and being happy with it is imho a cardinal sin.

Mostly because a lot of additional and custom rules can and should be implemented / added...

After all, Sonarqube is an expensive solution. Just sticking to defaults is wasting a lot of potential.

Sheesh. But who cares about money, I know. XD :-)

@Augmental That sounds way out of scope for CTO, guess he‘s just a control freak without actual insight. Classic.

This is evil. Tools like this are meant to help us, not to become our masters.

I've seen some rules that IMO should be stricter.

But the bottom line is that the team should decide what they want to enforce or not and the tool should help them to do that.

We create software. We don't work for software.

@IntrusionCM I've only seen large tech firms and some seasoned individuals do that properly. Everyone else just sticks to the defaults or uses some "big name" pre-set that's way too rigid for anything that doesn't involve large groups of developers.

We had a very similar problem
We managed to have the sonarqube gates at least not as a build breaker but only informative. Finally we managed to convince them we could add sonar ignore files tonour repositories so we can ignore certakn rules ( or exclude classes from coverage)

Depending on your build sonarqube might read igbore fules from. the repo automatically, you could try to sneak one in.