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 ServicePersonis 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.
