Hello,
our team has a new idea for a feature. We already encountered two problems with the autofix-function for specific rules. The rules itself are very useful but the autofix is wrong or not recommended (too many side effects). Also, some developers are saving while writing new code and the autofix-function kicks out eg. unused (or better say “not used yet”) Variables
So we don’t have to relinquish completely the rules we wanted to turn off the autofix-feature in the EditorConfig where we also control the severity. A solution could look like this:
dotnet_diagnostic.SA1202.autofix = false
It would be so cool if you add this feature in a future version!
I’m going to flag this for the SonarLint team, but IMO turning off the autofixes should be an absolute last resort. Instead, we’d far rather fix them. Would you mind identifying the rule(s) and fix(es) in question?
The other one was S1481 (but I won’t create an issue for that):
My team is used to it to save up regularly. Now if you write a function and declare the variables in the beginning because you want to use it later - save up - it’s gone. So for that rule we definitely need to disable the autofix-function.
I understand that you want to eliminate the root cause. Nevertheless, I see the advantage of having this feature (which is also offered by roslyn-analyzers). It would be cool if we can customize it more (for disabling autofix for until the problem is fixed or even to disable it for specific rules)
Second, it seems to me (feel free to correct me if I am wrong), that this is an IDE (Visual Studio) feature, not a Sonar one, and that it is controlled through two things:
Analyze/Code Cleanup/Configure Code Cleanup to choose which code cleanups are applied for a given profile
Tools/Options/Text Editor/Code Cleanup to enable/disable auto apply of a specified profile on save
Do you mean that you specifically cannot control those through this setting? Or is it that you would want a way to share the setting at the project level and not on individual VS setups?
Indeed, there is this function in Visual Studio. Here, you can configure which rules are applied. We only have one rule that is activated: Fix all warnings and errors set in EditorConfig
The .editorConfig is on our root-level, shared among the different developers via Source Control. We want a more specific approach where we manage individual rules that are perfect for our needs. For example, turn off specific rules we don’t need or lower the severity.
Sometimes we think the rule is useful, but the autofix-feature is not. Therefore, we want to control this specifically for each rule in the .editorConfig. At the moment, we have to turn off the whole rule if we don’t want the autofix.
Example of .editorConfig:
dotnet_diagnostic.S1144.severity = silent
dotnet_diagnostic.S125.severity = suggestion
dotnet_diagnostic.S112.severity = silent
# this would be the new feature to just turn off the autofix
dotnet_diagnostic.SA1202.autofix = false
I hope it’s more clear now, why we need this feature. Feel free to ask any questions
Thank you for explaining. Would you mind sharing your EditorConfig as it is today, as well as the version of Visual Studio you are using?
I would like to be able to reproduce your issue exactly before responding more precisely.
we use "Microsoft Visual Studio 2022 (64-bit) (VS version is 17.7.5)
I attached you our .editorConfig as a .txt-file because .editorConfig is not an allowed extension for upload. The comments are in German, but you can see which rules we disabled completely because we don’t want the autofix-feature. editorConfig.txt (5.7 KB)
If I take rule 1481 (remove unused local variables) as an example, I see you have it silenced in your .EditorConfig file.
However, Sonar does not provide a quick fix for this one (as seen on C# static code analysis: Unused local variables should be removed). And, moreover, as far as I know, Visual Studio only applies internal (Microsoft’s own) quick fixes on Code Cleanup.
In my setup, with your EditorConfig, whether I silence the rule S1481 in EditorConfig or not, if my CodeCleanup setup (which is VS-specific, only editable through UI in the Analyze menu) has the “remove unused variables” fixer, it will be applied on save (if the CodeCleanup on Save checkbox is checked in the Options of course).
Firstly, we know that rules by SonarLint and StyleCop are autofixed. For example the spacing and spaces are fixed by StyleCop. In the ticket because of S1172 that I linked above the developer could reproduce my problem.
I suspect that your settings of the code cleanups aren’t correctly. Could you please share them?
Secondly, I wrote two issues on GitHub for S1125 and S1172, which have an autofix-function. For these rules, we would need that feature. Sorry, if the other comment is wrong in our .editorConfig - I will forward it internally.
I think I understand now. I had missed the “Fix all warning and errors set in EditorConfig” Code cleanup entry, which is what ropes in the autofix from Sonar’s rules I think.
So, to summarize:
If Code cleanup is configured to apply all fixes from EditorConfig
And Apply Code cleanup on save is set
And rule S1172 (for example) is not silenced
Then, upon saving the file the undesired (because they are broken) auto fixes are applied, resulting in broken code.
Therefore, you would like fine-grained control over which autofixes are activated in EditorConfig for Sonar’s rules.
This would allow deactivating fixes that you do not want while keeping others.
Is that correct?
For the time being, I would probably remove the “Fix all warning and errors set in EditorConfig” and “Remove unused variables” entries from the Code cleanup configuration to limit the damage on your code base.
Additionally, some rules aren’t broken, but we just don’t want the autofix. We just don’t want them be autofixed We only have the entry “Fix all warning and errors set in EditorConfig” active - it’s saving us a lot of time because we don’t need to format our code anymore.
So we will definitely stick with the .editorConfig-solution - hoping that you will add this feature so we can have our rules and our autofix
Happy to hear we understand where your pain point is.
I will make a note of your requirement, but keep in mind this might not be technically possible at our level. I would definitely urge you to open an issue with Roslyn for such a feature (Issues · dotnet/roslyn · GitHub) because they seem to be driving the work on those things and it should probably be a feature at this level (since that is the common mechanism between VS and VS Code).
I think dynamically changing the availability of code-fixes is not possible for SonarLint. I posted a message on your issue to push the idea of including this in EditorConfig as it seems to me a very good idea. Hopefully the Roslyn team will prioritize that!
