rehansaeed/editorconfig

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

A very generic .editorconfig file supporting the following file types:

• C# - .cs, .csx, .cake
• Visual Basic - .vb, vbx
• Script - .sh, .ps1, .psm1, .bat, .cmd
• XML - .xml, .config, .props, .targets, .nuspec, .resx, .ruleset
• JSON - .json, .json5
• YAML - .yml, .yaml
• HTML - .htm, .html
• JavaScript - .js, .jsm, .ts, .tsx, .vue
• CSS - .css, .sass, .scss, .less, .pcss
• SVG - .svg
• Markdown - .md
• Visual Studio - .sln, .csproj, .vbproj, .vcxproj, .vcxproj.filters, .proj, .projitems, .shproj
• Makefile

.NET Code Style

Extensive code style settings for C# and VB.NET have been defined that require the latest C# features to be used. All C# related code styles are consistent with StyleCop's default styles, with the exception of the file header definition, which has been changed to a more modern format. All .NET naming conventions are consistent with the .NET Framework Design Guideline's Naming Guidelines.

What is .editorconfig?

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems. Find out more at editorconfig.org and the Visual Studio Docs.

How do I use It?

All you have to do is drop it into the root of your project. Then any time you open a file in Visual Studio, the .editorconfig file settings will be used to help format the document and also raise warnings if your code style and formatting does not conform. For Visual Studio Code, you can install the EditorConfig for VS Code extension to get support.

How can I get it?

Download the .editorconfig file in this repository or you can install the .NET Boxed templates and use the dotnet new CLI to create a new .editorconfig file in you current directory like so:

dotnet new --install Boxed.Templates
dotnet new editorconf

editorconfig's Issues

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.

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/

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

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

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

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}].

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

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.

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?

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

New Spell Check Setting

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

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

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

Bad globbing pattern for csharp section

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

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.

Add .cshtml to Web Files Indent Config

Would be nice as this is the file extension used for .NET Razor Pages

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?

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

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.

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?