In software development, ensuring uniform coding styles across different editors and IDEs is challenging. .editorconfig files offer a universal solution to this problem, transcending language and platform boundaries, including .NET. These configuration files standardize coding practices, helping developers maintain consistent code regardless of their tools. This article delves into the role and usage of .editorconfig in .NET projects.
.editorconfig as a textual file format
The .editorconfig project (see the website https://editorconfig.org/ ) defines a textual file format designed to outline coding styles, along with a suite of text editor plugins that allow editors to interpret this format and comply with the specified styles. .editorconfig files are straightforward to read and integrate seamlessly with version control systems.
The .editorconfig file content shown below sets a default indentation style of 3 spaces for all files but specifically alters this to 2 spaces for .json files. Then it defines some C# style preferences:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# A newline ending every file # Use 3 spaces as indentation [*] insert_final_newline = true indent_style = space indent_size = 3 [project.json] indent_size = 2 # C# files [*.cs] # New line preferences csharp_new_line_before_open_brace = all csharp_new_line_before_else = true csharp_new_line_before_catch = true csharp_new_line_before_finally = true csharp_new_line_before_members_in_object_initializers = true csharp_new_line_before_members_in_anonymous_types = true csharp_new_line_between_query_expression_clauses = true # Indentation preferences csharp_indent_block_contents = true csharp_indent_braces = false csharp_indent_case_contents = true csharp_indent_switch_labels = true csharp_indent_labels = one_less_than_current |
Textual file format is convenient. Commit the .editorconfig file to your source control system to share it with your team. The coding styles defined in the file will be automatically enforced by compatible editors and IDEs used by the team members.
Organization and Priority of .editorconfig Files
.editorconfig files apply settings hierarchically, affecting files in their directory and all subdirectories. You can override these settings at any level by placing a new .editorconfig file in a subdirectory. In the example below, .editorconfig (B) overrides settings in .editorconfig (A).
|
1 2 3 4 5 |
├── .editorconfig (A) ├── MyApp.sln ├── src │ ├── .editorconfig (B) │ ├── MyProject.csproject |
By setting root=true in the .editorconfig file at a specific level, you can prevent the inheritance of settings from parent directories. This feature is particularly useful when you do not have control over the files in higher-level directories.
|
1 2 3 4 |
# top-most EditorConfig file root = true ... |
.editorconfig and .NET
Microsoft adopted .editorconfig for C# VB.NET and F# starting with Visual Studio 2017.
Visual Studio supports .editorconfig files natively but VSCode requires this EditorConfig for VS Code extension to handle it. Concerning JetBrains Rider, by default the IDE adheres to .editorconfig settings, which will supersede any preferences set within JetBrains Rider’s own settings. Should you wish for JetBrains Rider to disregard .editorconfig styles concerning code formatting and syntax, simply uncheck the relevant box located in the Editor > Code Style > General section of the JetBrains Rider settings.
In Visual Studio you can create a new .editorconfig file this way:
Visual Studio proposes a sweet User Interface to deal with C# and .NET editor config settings.
- Settings are grouped into 4 categories, Whitespace, Code Style, Naming Style, and Analyzers.
- Observe the convenient Search Settings textbox, designed to navigate through the multitude of settings, styles, and analyzers.
- For each setting, you can see and change the value and also see the location from which it is inherited.
Applying settings changed within .editorconfig
Be aware that modifying a setting such as Indentation Size and saving the .editorconfig file does not automatically adjust the formatting in any concerned source files. Instead, the source code editor will display squiggles, indicating that the tab settings from the .editorconfig are not in effect in the file being edited. To correct the tabs, you can execute Code Cleanup on the file. Additionally, there is a feature (found under Tools > Options) that allows you to automatically perform Code Cleanup whenever a source file is saved.
Notice you can run Code Cleanup globally from this solution menu. In our example, it would adjust Indentation Size within all source files.
.editorconfig and Roslyn Analyzers
The editor config’s Analyzers section refers to Roslyn Analyzers. Starting with Visual Studio 2019 version 16.5, rule set files have been superseded by .editorconfig files for the configuration of analyzers for managed code.
Looking at the textual view, configuring Roslyn Analyzers looks like this.
|
1 2 3 4 5 6 7 8 9 10 |
# StyleCop: Spacing Rules [*.cs] dotnet_diagnostic.SA1000.severity = none # Keywords should be spaced correctly. dotnet_diagnostic.SA1001.severity = suggestion # Commas should be spaced correctly. dotnet_diagnostic.SA1002.severity = none # Semicolons should be spaced correctly. dotnet_diagnostic.SA1003.severity = suggestion # Symbols should be spaced correctly. dotnet_diagnostic.SA1004.severity = suggestion # Documentation lines should begin with single space. dotnet_diagnostic.SA1005.severity = suggestion # Single line comment should begin with a space. dotnet_diagnostic.SA1006.severity = none # Preprocessor keywords should not be preceded by space. dotnet_diagnostic.SA1007.severity = none # Operator keyword should be followed by space. |
The severity ranges into:
- none: (Disabled into the UI), the analyzers gets ignored.
- silent: (Refactor Only into the UI). It means that Visual Studio will still present the code fix through a light bulb refactoring action, despite the user not being able to see the underlying hidden diagnostic.
- suggestion: Violations are displayed in the Message tab of the Error List window, yet they do not appear in the output of command-line builds. In the editor the issue is underlined with a gray squiggle line.
- warning: Violations are shown in the Warning tab of the Error List window and are included in the output of command-line builds, but they do not lead to build failures. In the editor the issue is underlined with a green squiggle line.
- error: Violations are displayed in the Error tab of the Error List window and in the output of command-line builds, leading to build failures. In the editor the issue is underlined with a red squiggle line.
Btw, you might be interested in reporting newly introduced Roslyn Analyzers’ issues directly from your CI/CD pipeline with our tool NDepend as explained in the link:
Conclusion
.editorconfig files offer a simple yet powerful mechanism for enforcing consistent coding standards across .NET projects. By integrating these files into your development workflow, you can significantly improve code quality, enhance team collaboration, and streamline the development process. Remember, the goal of using .editorconfig is not to restrict developers but to create a more cohesive and efficient coding environment.