rehansaeed / editorconfig

A very generic .editorconfig file supporting .NET, C#, VB and web technologies.

I am a professional Software Developer at Microsoft and blogger at RehanSaeed.com. Although I work for Microsoft, my opinions are my own. If it’s written in C# or .NET, I have probably written something using it in anger!

I live stream my software development escapades on Youtube and Twitch twice a week. Feel free to join me live and ask questions.

‏‏‎ ‎

You can see some of the open source projects that I have started and maintained in my portfolio. There are many others I have contributed to which you can see in my GitHub profile and of course there are other commercial projects that I cannot disclose.

‏‏‎ ‎ ‏‏‎ ‎

I have been fairly active on StackOverflow. You can view my Stack Overflow profile and see my contribution to the community.

Before I joined Microsoft, I was a Microsoft Most Valuable Professional (MVP) for three years. This gave me inside information into the work Microsoft was doing. Once I joined Microsoft, I had to give up this award.

Here are some of the awards I have been given for my work as a software engineer in open source or elsewhere:

Do you have questions or comments about my work? Please feel free to contact me.

editorconfig's Issues

New Settings in VS 16.11

Edit: Moved these settings to: #76. More settings listed below.

See dotnet/roslyn#50358

# IDE2000, AllowMultipleBlankLines
dotnet_style_allow_multiple_blank_lines_experimental = false:warning
# IDE2001, AllowEmbeddedStatementsOnSameLine
csharp_style_allow_embedded_statements_on_same_line_experimental = false:warning
# IDE2002, AllowBlankLinesBetweenConsecutiveBraces
csharp_style_allow_blank_lines_between_consecutive_braces_experimental = false:warning
# IDE2003, AllowStatementImmediatelyAfterBlock
dotnet_style_allow_statement_immediately_after_block_experimental = false:warning
# IDE2004, AllowBlankLineAfterColonInConstructorInitializer
csharp_style_allow_blank_line_after_colon_in_constructor_initializer_experimental = false:warning

A severity must be specified on modifier preferences

Describe the bug

when open the editorconfig file getting a message (EC104):

A severity must be specified

To Reproduce

Open editorconfig in Visual Studio

Expected behaviour

don't see the squiggle lines.

Bad globbing pattern for csharp section

[.cs,csx,cake]
should be
[.{cs,csx,cake}]

Suggestion: dotnet new tool

Hi,

I thought it would be a good idea to have a dotnet new editorconfig

Maybe we can have something like @paule96 build here:
https://github.com/paule96/paule96.DotNetTemplate.GitIgnore

This is not an Issue, instead it should be used for discussion.

What do you think?

Renaming master Branch to main

The default branch name for GitHub and Git has changed to main. To avoid having to remember the default branch name and also for ethical reasons, I propose renaming the master branch to main.

More info here:
https://www.hanselman.com/blog/easily-rename-your-git-default-branch-from-master-to-main

Is there a way to enforce const to be real Pascal Case only?

Currently, there is no way to prevent the const fields to use all upper case. Even though in .editorconfig, already defined to be pascal_case only, but it doesn't seem to be able to differentiate all_upper vs pascal_case. Any workaround for this?

Upgrade to new Severity Syntax for VS 16.9

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.

File Header Comments

.editorconfig has a new feature letting you add a file header comment:

https://docs.microsoft.com/en-us/visualstudio/ide/reference/add-file-header

We should consider adding this but maybe commenting it out by default as it's not a feature that everyone would want to use.

Adding .editorconfig breaks TreatWarningsAsErrors

Describe the bug

Adding the .editorconfig file from repo main breaks TreatWarningsAsErrors

To Reproduce

1. Download the attached project ErrorsTest.zip
2. Set build configuration to Release and build.
3. StyleCop warnings are not treated as errors and do not cause the build to fail.
4. Remove .editorconfig file and rebuild. Build will fail.

Expected behaviour

When the build configuration is set to release the build should fail.

Rules

Provide links to any rules in question.

New Settings in VS 16.10

VS 16.10 adds new settings. Settings are suffixed with _experimental. Wait for it to be released before adding.

See dotnet/roslyn#50358

# IDE2000, AllowMultipleBlankLines
dotnet_style_allow_multiple_blank_lines_experimental = true
# IDE2001, AllowEmbeddedStatementsOnSameLine
csharp_style_allow_embedded_statements_on_same_line_experimental = true
# IDE2002, AllowBlankLinesBetweenConsecutiveBraces
csharp_style_allow_blank_lines_between_consecutive_braces_experimental = true
# IDE2003, AllowStatementImmediatelyAfterBlock
dotnet_style_allow_statement_immediately_after_block_experimental = true
# IDE2004, AllowBlankLineAfterColonInConstructorInitializer
csharp_style_allow_blank_line_after_colon_in_constructor_initializer_experimental = true

See dotnet/roslyn#49990

dotnet_style_namespace_match_folder

See dotnet/roslyn#55005

csharp_style_prefer_null_check_over_type_check

New Spell Check Setting

https://learn.microsoft.com/en-us/visualstudio/ide/text-spell-checker?view=vs-2022

Is there a rule to control empty line between class members declaration

like this question https://stackoverflow.com/questions/54729468/formatting-rule-to-have-blank-line-between-class-member-declarations

New Formerly Experimental Settings

Describe the feature

Several settings are currently experimental but will soon be published formerly:

• dotnet/roslyn#60539

When this happens, update the .editorconfig.

Rules

# IDE2000, AllowMultipleBlankLines
dotnet_style_allow_multiple_blank_lines_experimental = false:warning
# IDE2001, AllowEmbeddedStatementsOnSameLine
csharp_style_allow_embedded_statements_on_same_line_experimental = false:warning
# IDE2002, AllowBlankLinesBetweenConsecutiveBraces
csharp_style_allow_blank_lines_between_consecutive_braces_experimental = false:warning
# IDE2003, AllowStatementImmediatelyAfterBlock
dotnet_style_allow_statement_immediately_after_block_experimental = false:warning
# IDE2004, AllowBlankLineAfterColonInConstructorInitializer
csharp_style_allow_blank_line_after_colon_in_constructor_initializer_experimental = false:warning

Add Sample Project

A sample project exercising all rules and using the new Microsoft.CodeAnalysis.CSharp.CodeStyle NuGet package to enforce rules through build failures.

https://www.strathweb.com/2020/01/enforcing-c-editorconfig-formatting-conventions-at-build-time/

Version 4.1.0 still says "4.0.0" on the file header

Describe the bug

Latest version on the project is 4.1.0 as per https://github.com/RehanSaeed/EditorConfig/releases , however when looking at the file's contents, the header still says it is version 4.0.0:

EditorConfig/.editorconfig

Lines 1 to 2 in 4b0d5bc

	# Version: 4.0.0 (Using https://semver.org/)
	# Updated: 2021-10-12

Aparently, the update date also doesn't match with the newest version.

Expected behaviour

File version should match the release version to avoid confusion for consumers.

csharp_using_directive_placement = inside_namespace don't warn about using outside namespace

version 1.6.1 had csharp_using_directive_placement = inside_namespace:warning

Since version 2.0.0 removed the :warning I dont get the warnings and Quick Action don't suggest to move usings inside namespace

Support New Settings

csharp_prefer_simple_using_statement
csharp_prefer_static_local_function
csharp_using_directive_placement

See https://github.com/MicrosoftDocs/visualstudio-docs/issues/1070

Support for .razor files

Maybe I did something wrong but is there a way to be able to use all the c# settings also in *.razor files?

Improved .editorconfig compliance with .NET guidelines

This is a somewhat long post, expanding somewhat on Dotnet-Boxed/Framework#22.

TLDR;

1. Split naming rules into those specified by the .NET naming guidelines, and those which are user-preference.
2. Make it clearer where users can add customizations and overrides without stepping on the .NET naming guidelines.
3. Make it annoying to use public fields that are disallowed by the .NET Design Guidelines.

Foundational Background

• https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/protected-members
  Protected fields should be treated as public, according to .NET design guidelines.
• https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/field
  The same .NET design guidelines drastically limit allowed public fields, by allowing only two exceptions.
• https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members#names-of-fields
  The naming convention guidelines explicitly exclude internal and private fields. Thus, even if allowed, these are entirely user preference.
• Historically, even .net source code has used multiple naming conventions for private and internal fields. Specifically, both camelCasing and the use of an underscore prefix with PascalCasing have existed.

Because of the above, the state for a given field is defined by:

• {true|false} field type allowed by the .NET design guidelines
• {null|pascal} naming convention specified by the naming guidelines

The recommendation is to split field name formatting as follows:

1. {true, pascal} == public const, protected const
2. {true, pascal} == public static readonly, protected static readonly
3. user-specified rules for private, internal, and protected fields
4. {true, null} == catch-all for private, internal, and protected internal fields
5. {false, *} == any other type of field not in above categories

Wrong scope for dotnet severity

Hi,

currently the severity for dotnet_analyzer_diagnostic is under the 'Makefile' scope.

I guess it should be somewhere under [*.{cs,csx,cake,vb,vbx}].