parent | title | nav_order |
---|---|---|
EditorConfigs |
Selection |
1 |
Assuming you do not already have one, your options for selecting an EditorConfig are to:
- Start from scratch
- Create from your Visual Studio settings
- Use the default Visual Studio settings
- Use the .NET Core Runtime or Rosyln Compiler EditorConfigs
- Use the Minimal Style as Code EditorConfig
- Use the Style as Code EditorConfig
The advantages of each option are presented below.
Pros:
- Existing Visual Studio setting will be honored
- You have control over how rules are configured
- You'll likely learn more about the individual rules than would otherwise be the case
Cons:
- More time spent creating the EditorConfig
- Any missing rules will instead be configured by whatever IDE instance the project is opened with (so different settings for IDEs, devices, and contributors)
Pros:
- You have control over how rules are configured
Cons:
- You may not have spent time deciding on if the defaults are best, or if your changes follow best practices
Pros:
- The defaults are a fairly good starting point
Cons:
- You'll need or want to invest time reviewing the best practices to make changes to rule configurations
.NET Core Runtime EditorConfig
Pros:
- You'll be adopting a set of rules that are used by one of the largest C# projects with many contributors
Cons:
- You won't get as much control over rule choices
- You'll need to decide on which one to adopt, and that isn't straightforward
As to why picking one isn't straightforward, as of February 2020 between the files there are:
- 148 C# rules defined
- 58 are equal
- 25 are not equal
- 74 are only defined in one EditorConfig
You can read more about the differences here.
Pros:
- Only includes rules that appear and are equal in both the .NET Core runtime and Roslyn Compiler EditorConfigs
- You get to decide which rules to add and how to configure them
Cons:
- You'll have to invest more time learning about the rules, configuring them, and modifying the EditorConfig
- With many rules missing, contributors will still be relying on some rules as configured in their IDE installations
Style as Code Minimal EditorConfig
Pros:
- The rationale for all rule decisions should be available here
- It should be easier for you to reach 0 warnings and suggestions
- The file is divided into sections of related rules
- The file has comments that pair rule IDs and descriptions with configuration lines
- Some rules are grouped and noted as being those which should be toggled on and off during refactoring
- It will eventually cover settings for Roslyn Analyzers beyond the built-in ones
- The file is versioned and iterated upon as more information is added to the best practices documentation
Cons:
- You might disagree with some rule configurations
- The file will be updated over time, so you may fall behind on the best practices being recommended