In my current project, I am dealing with a lot of autogenerated code. I do want to analyze the generated code with SonarQube on several aspects such as security issues. However, a lot of issues and code smells don’t really apply.
For instance, Refactor this function to reduce its Cognitive Complexity from x to the x allowed is useless. This holds for many other things as well (Rename method “XXXX” to match the regular expression [1][a-z0-9_]$, …)
As a new feature, I’d suggest a flag like sonar.autogenerated that can be set on the root level sonar-project.properties file to handle autogenerated files with a fixed set of rules. Which rules exactly apply must be further investigated.
A more general feature that could be implicitly used to simulate what I am suggesting:
Flag that facilitates that rules can be generally enabled/disabled for specific paths.
Yes, the main idea is that only some rules apply for autogenerated code. I was not aware of the linked feature and that could certainly be used to achieve what I want.
However, the main idea behind sonar.autogenerated was:
sonar.autogenerated should be a flag that can be enabled for file paths. It is not manually populated but rather comes with a fixed subset of rules. Obviously, these fixed predefined rules won’t apply for any case of autogenerated code but the flag comes in handy if these rules do apply. I think in most cases, it is pretty straightforward which rules do apply and which do not.
Extemporary, I’d say, I want to be notified about every security issue in my autogenerated code but for any other code smell that is related to code complexity, code style, naming conventions, etc…, I simply don’t care.
I am new to SonarQube, maybe this is not the best idea for some reason, but it seems reasonable to me
I think it’s quite hard to detect them automatically and reliably. You’d probably always have some false positives and false negatives and they will then only cause more pain for the developer.
