With SonarQube version 10 you introduce quite a change with Clean Code and Software Quality attributes. It makes some sense, however, for us it has some unpleasant side effects.
We have developed a set of custom rules which focus on performance and sustainability. They all map to Clean Code - Consistency and Software Quality - Maintainability, which does not make sense. Our tags and severity levels are not well represented anymore.
Performance and Sustainability are important to us and they provide business value. We see those as Software Quality attributes, next to Maintainability, Reliability and Security. We donât see that now, and weâd like to see that reflected in Sonar dashboards and Quality Gate. How can this be achieved?
Performance and Sustainability are important for us too. We use custom Quality Gate based on serverity by this way we can select which rules âblockedâ the quality gate.
We do want to expand on the software qualities that a rule/issue can impact. Sustainability along with Accessibility are two candidates we are exploring at the moment. We are thinking along the same lines as you; label on rules alongside security/reliability/maintainability, dedicated rating, card in project/portfolio summaries and quality gate conditions.
Your point about performance is also a good one and weâll have a think about how that fits into this space as well.
We donât have target dates on these new qualities just yet. You can sign up for notifications (and vote) on those cards if that would be helpful.
Nice, I just voted for Sustanability, with the following comments:
Sustainability is very important to us, it adds business value to be able to work on it in a prioritized way. It helps to save energy, save the environment and save costs. We have developed a custom ruleset with about 128 rules of which 63 are classified as sustainability: low, medium or high. Next to sustainability, we also have 79 classified under performance, 32 multi-threading and 10 data-mix-up. There is much overlap, most rules have more than one tag. Multi-threading could be under the quality Availability (or Stability). Data mix-up would fall under Security. We would like very much to see the Qualities extended with Sustainability, Performance and Availability. For the ruleset, see GitHub - jborgers/PMD-jPinpoint-rules: PMD rule set for responsible Java and Kotlin coding: performance, sustainability, multi-threading, data mixup and more.
Thank you for this additional information, this is hugely helpful! Could you say a bit more about the difference between your proposed âAvailability/Stabilityâ and the quality we have currently called âReliabilityâ please?
Good to read; and a good point, they are different in a subtle way (e.g. explained here: Reliability vs availability: Understanding the differences).
However, I think Reliability would do and we donât really need the extra quality Availability/Stability.
How does this work, can we expect progress on getting Sustainability and Performance as Qualities in SonarQube?
Does it help to have more votes on the idea through the link you mentioned? Does that cover Performance, too?
Yes, the more votes we receive on the idea, the better our chances of getting Sustainability and Performance recognized in SonarQube. Every vote counts!
If you have specific needs or suggestions, I encourage you to share them with your sales representative as well.
By the way, itâs great to see that there are not just French banking institutions interested in Sustainability.
Good, I asked some colleagues who agree to vote, and I see some more votes already. Maybe you can do the same?
Yes, weâll talk to the sales rep.
Are many French banks interested?
We particularly value information about the particular use cases or constraints different users have. That way, we can see the value we could bring and also get a feel for the exact problem we need to solve. I wouldnât worry too much about getting the vote count to be particularly high.
Every vote counts!