I want a consistent number of findings with a predictable behavior of the findings.
Performed analysis repeatedly.
I am beginning to see a number findings showing up from Sonarqube of essentially legacy findings. Today I opened master’s analysis and found a “new” finding on a line which hasn’t been touched since 2021. The nearest, recent change was done 30 lines away.
Is there an explanation for this behavior or is there a bug resulting in these findings reappearing?
There are a small number of rules that can be influenced by other changes to a file or a change in the file, or other external factors (change of language version, dependency, etc.)
Hi Colin.
It is C++ code and the finding in the latest case was cpp:S105 “Replace all tab characters in this file by sequences of white-spaces.”
We recently switched updated our C++ version from 14 to 17 but I wouldn’t expect that to have any impact on this.
While I started doing some testing, I realized cpp:S105 is not enabled by default. Can you check the changelog of the Quality Profile applied to this project to see when this rule was enabled?
It also might be worth checking the Activity tab of your Quality Profile to see if there was a change in which Quality Profile is being used.
Backdating should kick in in both of these cases, but I’d like to start here.
(My other theory is that we do something weird with New Code/Issue detection when only whitespace has changed, but that’s just a theory at this point)
cpp:S105 behaves badly by raising a file-level issue on the first instance of using tabs instead of spaces, rather than reporting a genuine file-level issue that is not tied to a specific line.
SonarQube’s detection of changed lines ignores whitespace – which is intentional but has some unexpected consequences
I forked one of our C/C++ Example Repos (here’s my fork) and analyzed it with SonarQube Cloud’s Automatic Analysis.
Ignoring whitespace when detecting changed lines is intentional, but it’s pretty confusing in this case since the change in whitespace is causing an issue to be raised. Even further, the blame data for those changed lines is now wrong in SonarQube.
In the meantime, it’s worth noting that the issues in your codebase are probably indeed new and that somebody committing to your repo might have their IDE configured to use spaces instead of tabs. SonarQube won’t show that blame data, but your Git history should.
Hi Colin.
Thanks for the update - glad to hear it wasn’t just me misinterpreting the concept for once. I look forward to hearing the answers from the teams.
Hi Colin.
Returning from Christmas I have found a number of findings that seem to have reappeared as new.
E.g. I see a “new” finding of cpp:S5950, “Use “std::make_unique” to construct “std::unique_ptr””. The code defining this variable and instantiating it has not been touched for more than three years. On the same line I have a preexisting findings, cpp:S5025 - " Replace the use of “new” with an operation that automatically manages the memory" and this is also present on our release branches.
cpp:S5950 has not been added to the quality profile recently and there has been no upgrade to the server.
Any good ideas why this shows up now?
This rule (cpp:S5950) varies in the issues it will raise based on the C++ standard detected. Is it possible that something changed here?
While it can be overridden (as the docs indicate), SonarQube typically picks up this information by what standard is passed to the compiler (if the standard is not explicitly passed to the compiler, the default C++ standard version for the compiler is used for the analysis).
That assumes, of course, that you’re using the compilation database rather than AutoConfig.
We changed our C++ standard two months ago and we saw several new suggestions back then.
We do use a compilation database but set up the C++ version in the configuration file - can that cause potential problems?
The server running SQ was restarted during the christmas holidays. Can there be anything lingering that is reset during a restart? I don’t remember when the server was last restarter prior to this.
