I am currently introducing SonarQube as part of our delivery pipelines. It should act as a build breaker if a PullRequest contains bugs or changes that are not compliant with our quality gate. We have a large existing codebase. Thus there are a lot of already existing issues which are now detected by SonarQube (which is great. I love SonarQube. It is an awesome tool). After introducing SonarQube as a build breaker we ran into a problem which brought me to an idea for a new feature that would improve SonarQube even more.
Here is the scenario:
Due to our existing codebase we have a lot of violations of rules like “Cognitive Complexity” or “Too many method parameters”. While I absolutely agree that these rules are some of the most valuable rules in SonarQube to ensure maintainability of a codebase it creates a problem for us. Developers are enhancing or fixing things in a method which already have a “Cognitive Complexity” of e.g. 60 where 15 is the treshold. Thus this developer is now forced to refactor that method though he might have only added a log statement. In the perfect world I’d agree that she should do it immediately and get rid of that tech debt. But in our reality this is not always possible. Thus we struggle with having a rule like “Cognitive Complexity” as a build breaker rule for new code.
Long story short, here is my suggestion: What if SonarQube can differenciate between active and passive rule violations. I.e. in the concrete example it computes the cognitive complexity of the code as it was before a change and after the change. If the complexity has increased then we have an active rule violation. In that case the developer should be forced to fix the issue. If the complexity has not changed the I’d call that a passive rule violation. The developer has changed some code but not added complexity. He might even have decreased the complexity from 60 to 40, which would be a move towards the right direction. In such a case it would be great to be able to configure rules like “Cognitive Complexity” to consider “active” rule violations only.
What do you think? Does this make sense? For us it would be a great enhancement of SonarQube in order to apply it on already existing codebases.
This is exactly why we urge you to focus on issues on New Code. So while ideally she would reduce the complexity of the sections of the method she’s working on, the developer shouldn’t reasonably be expected to remediate the entire old issues. At minimum, she should only be expected not to exacerbate the issue by increasing the complexity.
Cognitive Complexity is a good example of a multi-location issue and I’m not certain of the exact mechanisms here. If the developer adds two points of complexity (new total 62) is the issue still considered “old” and not on her tab? I’m not sure.
But I am sure that the Cognitive Complexity issue will stay “old” in this case you’ve described. But these multi-location rules are a subset. So let’s set them aside. In general, if you focus on Issues on New Code - and that’s what the default Quality Gate is tailored to do - then your developers can get their jobs done without needing to fix the world. And in the meantime - as they do do work in old code - your overall quality will gradually rise.
Thank you for your reply. As suggested by you we already focus on new code only. We do this because of the reasons you mentioned. The overall quality will improve over time.
Nevertheless the scenario as described occurs: A developer adds a logging statement to a method. This does not increase the cognitive comlexity. But since the method already had a cognitive complexity above the treshold the issue is detected and the quality gate fails. And this happens although the quality gate operates on new code only.
Is there a chance that we have misconfigured something? Below you can see the configuration of our current quality gate.
Thanks and best regards
To be clear, the issue is detected as a new issue? Do you have an example you could share? I’d like to understand what’s going on there, since on the face of it that seems like a bug. Specifically, I’m interested in the last commit date on the issue line and on all secondary locations. This latter part would be satisfied with a screenshot showing whether there’s a yellow (new code) highlight on any 2ndary location lines.
Thanks again for your feedback. I’ll double check the scenario mentioned and provide you with the requested informations.
Thanks again for inquiring. The situations is not as I have described it initially. The problem occurs only if we modify a line which takes part in the cognitive comlexity computation. I.e. the example mentioned by me with the added logging statement was incorrect.
A concrete example was something like the following. We had a bug in a line like because it was not case insensitive
Thus a developer fixed the issue and the line now reads:
This change resulted in a “cognitive complexity” issue.
Hopefully such a fix is not necessary all to often. Thus I’ll close this request. Thanks again for helping to clearify my problem.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.