Upgrade to new Severity Syntax for VS 16.9 about editorconfig

[lonix1]

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 😞

[lonix1]

@maxild

You have to use microsoft.codeanalysis.csharp.codestyle.3.9.0-xxxxxx preview builds to get those files for explicit/recommended code style (IDExxxx) severity settings from there CI-feed

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?

Wish dotnet was more like GO (gofmt) wrt code styles

YES!!! Code style is such a waste of time, gofmt does it right.

[maxild]

https://dev.azure.com/dnceng/public/_packaging?_a=package&feed=dotnet-tools&package=Microsoft.CodeAnalysis.CSharp.CodeStyle&protocolType=NuGet

[maxild]

I have been working/following the code analysis .editorconfig/.globalconfig based changes in the .NET 5 SDK where code styles and code quality have been built into the sdk to be more cross-plat, and found your repo.

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.

[RehanSaeed]

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.

[lonix1]

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?

[RehanSaeed]

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 TreatWarningsAsErrors.

[maxild]

They publish a "default" set of severities for the code analysis rules, but I haven't found one for the code style rules.

The SDK uses global analyzer config files also distributed in the nupkg

dotnet/roslyn#49250 (comment)

[maxild]

You have to use microsoft.codeanalysis.csharp.codestyle.3.9.0-xxxxxx preview builds to get those files for explicit/recommended code style (IDExxxx) severity settings from there CI-feed...It is experimental, and will probably first come in .NET 6 SDK?

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.

[maxild]

Using warnings has the advantage of giving developers the ability to use TreatWarningsAsErrors.

This will only work probably when 16.9 ship dotnet/roslyn#43051 (comment)

[RehanSaeed]

Tested migrating from [rule] = [value]:[severity] syntax to [rule].[RuleId].[severity] in VS 16.10 and it still doesn't seem to work completely. At some point the old syntax will be deprecated (See dotnet/roslyn#44201). Not sure when that will be.

Raised #57 to fix this. Won't merge until issues are resolved.

[RehanSaeed]

Raised dotnet/roslyn#55542

[RehanSaeed]

Fixed in #75