I’m currently using SonarQube Community Edition v25, and I have a specific question regarding the configuration of “New Code.”
In my current project, I would like to define “New Code” as only the modifications made within the bodies of methods (e.g., changes to logic inside methods), and not structural changes like namespace modifications or imports in C# (.NET).
I’ve reviewed the options under the Analysis Scope section, including exclusions for files, blocks, and multiple criteria, but I couldn’t find a straightforward way to achieve this level of granularity.
Could you please advise if there is a way to configure SonarQube to focus “New Code” analysis exclusively on method content changes? Alternatively, is there a recommended workaround or approach to achieve this behavior (e.g., using regular expressions, custom rules, or external tools)?
Thank you for your support, and I appreciate any guidance you can provide!
It simply doesn’t work that way. New code is detected based on SCM data. Lines that changed within the new code period will be marked new, whether in or outside of a method.
Would you mind sharing why you want to omit structural changes?
Thank you for your quick response.
The reason I want to omit structural changes is related to our testing and quality assurance process. In our project, we have some legacy code that is already in production but not yet covered by unit tests. The general recommendation is to avoid making changes to such code just to address SonarQube issues, as this could introduce regressions.
However, we do require that any code considered as “New Code” must be covered by unit tests. If a file is marked as “New Code” only because of structural changes (such as namespace changes, function renaming, or import modifications), it creates unnecessary pressure to add tests for code that hasn’t actually changed in terms of logic or behavior.
That’s why I’m looking for a way to ensure that only substantive changes within method bodies trigger the “New Code” status, so we can focus our testing efforts where it really matters.
Thank you for any suggestions or best practices you can share!
Best regards,
Thanks for sharing those details. Would you mind also sharing your language and coverage engine?
I ask because IMO a package change or function renaming should not trip low-coverage conditions since they’re not “executable” (and thus not testable) code.
But unfortunately (in this case), when there’s a coverage report we go 100% by what the report says. So if your report indicates that the changed method name is “uncovered” then that’s how we report it.