The Joys (Not!) of SonarQube
Published at 22:05 on 9 February 2022
Or maybe I should say, “The Joys (Not!) of SonarQube As Implemented by My Employer.”
SonarQube is a code-analysis system. It analyzes computer code and enforces coding standards. If it doesn’t pass the sanity checks, builds don’t properly complete.
I have nothing in general against coding standards, and I fully admit that the code I write is not 100% perfect. I also have nothing in general against tools to help uncover questionable coding practices.
The problem is the automatic mandatory implementation, with it being like pulling wisdom teeth from an elephant to get any exemptions from.
Consider my recent use of a random number generator. It was in a bit of performance-sensitive code, and the random numbers were not being used for any cryptological or other security-sensitive purpose. The default (crap quality radomizer) Java ThreadLocalRandom
class was good enough, plus it had lots of convenience methods for doing things like generating a floating point number within an arbitrary range. So of course I used it.
Nuh-uh, no can do! SonarQube says that’s a security violation. I start inquiring about what can be done to get an exemption, and learn that it’s such a pain I’m better off recoding. So I do that, blowing a half day in the process (I have to implement a bunch of convenience routines missing from the SecureRandom
class).
It’s made worse by SonarQube itself being of generally shoddy quality. Its metric for there being enough test coverage so unreliable that a commit can pass muster on a branch, yet get failed when merged to master, even when the result of the latter merge is exactly the same as what was on the branch. That’s right: you have no idea if a merge to master will succeed or fail. Every merge might well prompt last-minute frenetic test-writing.
So I decide to write a boatload more tests, just to err on the side of high test coverage and avoid triggering the wrath of SonarQube. Everything works just fine on the branch, so I merge.
The build then promptly fails, because get this, the new code has insufficient test coverage.
That’s right, SonarQube is refusing to accept my test classes… because they themselves don’t have tests! Can you say “Catch-22” boys and girls?
Again, this wouldn’t be so bad (it would be more humorous than anything), if SonarQube were implemented in an advisory capacity instead of a mandatory one.
Actually, it’s still humorous. If they want to piss away their money on stupid policies that waste productivity, fine. I just make note of all the unnecessary busywork their policies cause and report as necessary when queried about why something takes so long. Their loss.