-
-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade to new Severity Syntax for VS 16.9 #46
Comments
I have been working/following the code analysis I am sure you already know, but just to be precise... I guess what you mean is the following # We currently use both the old
# csharp_prefer_braces = when_multiline:warning
# syntax and the new
# csharp_prefer_braces = when_multiline
# dotnet_diagnostic.IDE0011.severity = warning
# syntax (side-by-side, mixed, ??) as in
# csharp_prefer_braces = when_multiline:warning
# dotnet_diagnostic.IDE0011.severity = warning
# After 16.9 the old syntax should not be needed anymore
# but we should still probably keep it around for backward compatability.
# See also https://github.com/dotnet/roslyn/issues/44201#issuecomment-761672157 This should probably be put into the .editorconfig, such that people hand-editing the file will know. |
Yes that's correct. We should probably add a comment to that effect. I was hoping that we could transition to the new syntax by now so we wouldn't need to but that seems to have been delayed to VS 16.9. I'm also trying to understand when the old syntax will be deprecated but don't have an answer to that yet. |
Are the severities in your editorconfig based on your personal preference, or an official MS source? They publish a "default" set of severities for the code analysis rules, but I haven't found one for the code style rules. So I'm wondering how you decided on the severities for your config? |
We default to warning in all cases except very few where making it a hard requirement may make the code worse. We should probably review them. Using warnings has the advantage of giving developers the ability to use |
Yeah I thought as much. It's unfortunate they don't publish an "official" set like they do for code analysis rules. Defaulting to warning probably makes sense. Having a GUI tool like you mentioned in that other thread, makes even more sense. Something like those online gitignore tools would be cool. I'd do that myself if I had the time 😞 |
The SDK uses global analyzer config files also distributed in the nupkg |
You have to use I would argue that it is very difficult to enforce any styles for all projects. But with AnalysisMode/AnalysisLevel the SDK is trying. Therefore any editorconfig (also https://github.com/RehanSaeed/EditorConfig/blob/main/.editorconfig) is just a starting point. Wish dotnet was more like GO (gofmt) wrt code styles. |
This will only work probably when 16.9 ship dotnet/roslyn#43051 (comment) |
I checked this nupkg but it only has code quality rules. There aren't code style rules in there. Am I looking at the right package?
YES!!! Code style is such a waste of time, gofmt does it right. |
Tested migrating from Raised #57 to fix this. Won't merge until issues are resolved. |
Raised dotnet/roslyn#55542 |
Fixed in #75 |
See dotnet/roslyn#44201 (comment)
We currently use both the old
[rule] = [value]:[severity]
syntax and the new [rule].[RuleId].[severity] syntax side by side. After 16.9 the old syntax should not be needed anymore but we should still probably keep it around for backward compatability.The text was updated successfully, but these errors were encountered: