When we edit code (marked yellow), the existing issues below the edited line are reopened as new. The figure below illustrates this effect very good. The “new” issue is in old code. Apparently only the change of the line number is checked for the decision. Also the display is very confusing: When I want to see new issues, they are shown in a non-yellow code.
In our context the developers question the whole Leak Period method, if old issues are displayed as new every time a change is made.
Is this widespread, or do you have only isolated (this one?) examples?
Can you give some more details on the issue you’re almost showing? You’ve obfuscated everything that might help me understand which rule is at issue, as well as the issue date. If you’re telling me the issue is wrongly marked new, you could at least show me the date.
To be clear, this kind of behavior is expected with some rules.
In a larger project such effects are always very difficult to comprehend. We are therefore in the process of setting up an SQ demo server with a small demo project to be able to reproduce this exactly. We also plan to check this with different programming languages (C++ / Java) and internal and external issues.
But what I can already say for sure:
We are using SVN, the code with the new issue is definitely old, which we can see in the version history and also SQ mark it like this (is not yellow).
The issue was already in the code before, but was moved down a few lines by the change.
What confuses the users most: “New Issues” is shown in areas that are not marked yellow (not “New Code”).
There are cases where it is perfectly normal and expected for new issues to be raised on old code. I keep asking about the rule that’s raising the issue in question so I can evaluate whether this is one of those cases. If it is, I’ll explain why & we’re probably done. If not, then we’ll need to go further.
And then you give me the code you’re adding the issue with… Which implies the issue is being raised by a rule that’s not written/supported by SonarSource. Which is fine. The same new/old determination should apply regardless of who’s raising the issue. But I’m trying here to understand context.
So… What can you tell me specifically about the logic of the rule in question? What does it raise an issue on? Does it have 2ndary locations? [Anything else that might be useful about it]?
Based on this, it seems that the issue shouldn’t be new:
detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH
However, looking at the initial screenshot, I see that the block of added lines includes a conditional… which presumably added indentation to the issue line…? Which I guess could have changed the hash. (I don’t know whether or not we trim before the hash.)
What blame date does SonarQube have for the line in question?
I can’t answer the questions you posed in your previous reply. I’m referring this internally. And it would still be nice to know what rule we’re talking about. Since I understand now that we’re talking about C++ and I have the impression that this might be a rule you developed in-house, I need to ask whether we’re dealing with the Developer Edition($) C++ analysis or the community plugin.
on the identical server edition and version we are facing also problems for C#
First malicious example: rename a method, do not change it’s body => cyclomatic complexity is raised as new/open issue. No immediate coherence with the changed lines. Don’t mind if it’s obsolete, I could have reproduced the issue with any other method:
Second malicious example (changed lines marked red): only method body was changed, but SonarQube raised a new issue that the method should me made static. No immediate coherence with the changed lines:
Although I understand it may seem related, what you are describing is a different problem. Off the top of my head, it could seem like an analyzer update. Perhaps this code was originally scanned with an older version of our C# analyzer, and changing these few lines triggered a new analysis with an up-to-date version.
If that’s not the case, could you open a different thread for this issue, and tag it with csharp? This will attract the attention of the right people, so they can help you.