Editorconfig In Visual Studio In 10 Minutes or Less

Introduction: Why EditorConfig Matters

Tim begins by introducing the EditorConfig project, explaining that per-project settings are now easier than ever to implement. Instead of relying on personal preferences saved inside Visual Studio or editor settings, you can now configure a project to maintain a consistent coding style for all contributors.

Creating the Project

To demonstrate the EditorConfig file, Tim creates a new Blazor Server project in Visual Studio. He names it BlazorDemoApp and uses the default configuration. This simple .NET project serves as a test bed for setting and applying EditorConfig settings.

As Tim explains, this project doesn’t need complex logic or functionality. It’s just a convenient example for working with code style rules.

Understanding Project Preferences and Coding Styles

Here, Tim discusses why project-level configuration is important. In Visual Studio, each user can set preferences for things like:

• Whether to use tabs or spaces

• The indent size (e.g., 3 or 4 spaces)

• Placement of curly braces {} on the same or new lines

• The type of namespace declaration (block-scoped or file-scoped)

These preferences are usually stored per user in Visual Studio, not per project. Tim highlights that when working in a team, everyone’s local settings might differ. This can result in inconsistent code formatting, unnecessary diffs in version control systems, and time wasted aligning preferences manually.

That’s where the EditorConfig file format helps — it defines a shared set of EditorConfig properties that all developers’ editors can respect automatically.

Creating and Opening an EditorConfig File

Tim then shows how to add a new EditorConfig file to the solution.

He right-clicks on the solution and selects Add → New EditorConfig. Visual Studio might throw a small error when loading the file the first time, but Tim explains it’s a harmless quirk — just close and reopen the file.

This new file is typically named .editorconfig, and Visual Studio immediately recognizes it as a configuration document. It’s worth noting that Visual Studio supports this file natively, as do other text editors like Visual Studio Code and even Sublime Text, through text editor plugins.

Tim clarifies that EditorConfig is not a Microsoft-only tool. It’s an industry-wide standard that helps different editors understand and apply the same coding conventions, ensuring consistent formatting across multiple environments.

Configuring EditorConfig File Settings

Once the EditorConfig file opens, Tim explains that it pulls in default settings from the current Visual Studio configuration. However, these can be modified as needed.

He navigates to the Whitespace section, showing how to set:

• Use tabs instead of spaces

• Tab width = 3

These are examples of EditorConfig properties that define how code formatting should behave. Once saved, this configuration applies across the entire solution, but not outside it.

Tim notes that this EditorConfig file can also be added to version control systems (like Git), making sure that every developer who clones the repository inherits the same rules. This helps maintain consistent formatting regardless of who writes the code.

Working with Code Styles and Namespace Rules

Tim then dives into code style settings — specifically the namespace declaration style.

By default, C# uses block-scoped namespaces, where the namespace is defined with curly braces. Tim creates a class under the Data folder to demonstrate this format.

Then, he changes the EditorConfig file setting to use file-scoped namespaces. When he adds another class, Visual Studio automatically applies the updated style — showing the namespace with a semicolon (;) instead of braces.

This demonstrates how EditorConfig settings can influence the default code generation templates in Visual Studio, aligning automatically with defined project conventions.

Tim also points out that the code cleanup feature can be used to reformat existing files, ensuring all code adheres to the latest EditorConfig rules.

Setting Severity and Enforcing Rules

In this section, Tim focuses on how to control rule enforcement using severity levels in the EditorConfig file.

Each rule can have a value like none, suggestion, warning, or error. Tim sets the namespace rule’s severity to error, and immediately Visual Studio flags any file not matching the preferred format in the Error List window.

This ensures developers follow defined styles and prevents unwanted deviations in the current file or the entire project.

While some inconsistencies or Visual Studio bugs may appear (such as wrong suggestion prompts), Tim notes that these will improve over time. The important part is that the rules are applied consistently, making the code easily readable and uniform.

Multiple EditorConfig Files and Directory Scope

Tim goes on to explain that you can have multiple EditorConfig files in a single solution.

For example:

• A root EditorConfig file at the solution level defines general settings for all projects.

• A nested EditorConfig file in a subfolder like /Data can override some properties (e.g., naming conventions, tab width, or line breaks).

Each EditorConfig project behaves hierarchically — meaning files in subdirectories inherit from parent directories, unless explicitly overridden.

If you want to define the root of your configuration, you can set the property root = true in the top-level file. This tells editors to stop searching parent directories for more EditorConfig files.

This structure gives developers fine-grained control over project-level formatting rules, while still allowing special cases where different formatting might make sense.

Conclusion: Consistency Through EditorConfig

In his final remarks, Tim encourages developers to actively use EditorConfig in their .NET projects.

He highlights that this approach lets teams maintain consistent formatting rules, naming conventions, and layout styles — all without forcing personal editor settings changes. Each opened file automatically follows the defined styles set in the project’s .editorconfig file.

By committing these EditorConfig files into version control systems, teams ensure that everyone — regardless of their editor or environment — adheres to the same code formatting rules.

Tim concludes his video by emphasizing that the EditorConfig file format is simple, flexible, and widely supported. Whether you’re using Visual Studio, Visual Studio Code, or another text editor, it works nicely to help maintain consistent coding styles and keep your project clean, professional, and readable.