I noticed that when I change something in a line, Sonar re-reports all issues that were already present in that line before my modification. This happens even if my change only affects a single character.
It seems that Sonar relies on a line-based diff to determine which issues are “new”, so any modification to a line causes all pre-existing issues on that line to be considered as new issues again.
Would it be possible for Sonar to use a character-level or token-level diff instead, similar to git diff --word-diff --word-diff-regex=.?
This would allow Sonar to identify precisely what was changed and avoid flagging unrelated issues on the same line.
Is there a technical or design reason why Sonar doesn’t use a more granular diff (character or token level) for detecting new issues?
The assumption here is that when you work on a line you’ll work at the line level - and fix all the problems in the line - rather than at the character level.
IMO, that seems to be a reasonable assumption. Can you help us understand why you would just change a few characters in a line and not fix the other issues in the line?
Suppose you rename a variable. All the lines using this available will be changed.
That may create several issues per lines (ie a for loop, where the index use int instead int32_t, where the stop condition doesn’t depend only of the index, where parenthesis should be added in the condition, or the line is tool long…) . So you may finally have 20 or 30 issues.
And updating these lines may also create new issues.
The issue is worse when you change the name of a legacy function, which may have many problems (too long, too complex, too many branches…). That may become exponential. So you don’t dare anymore to change names to improve semantics.
And I don’t tlak of comment at the end of lines, changed because of encoding (yes, some ooold comments are not in english, and use diacritic characters).
@Oodini ,
Thank you very much for walking us through the scenario in detail. This really helped us understand your problem. We don’t hear this problem often. However, now we are tracking this need on our side.
