Configuring code style in Visual Studio 2017

I bring to your attention a translation of a useful article on how to configure and apply the rules for writing code in your team.

Visual Studio 2017 provides adherence to style of writing code and support EditorConfig. The new version includes more rules for the code style and allows developers to customize the style of code through EditorConfig.

What is EditorConfig?

EditorConfig is an open source file format that helps developers customize and apply formatting rules and coding style conventions to get more readable codebases (codebases). EditorConfig files are easily incorporated into version control and are applied at the repository and project levels. EditorConfig agreements override their equivalents in your personal preferences, so agreements from the codebase take precedence over the individual developer.

The simplicity and versatility of EditorConfig make it an attractive choice for the code style command parameters in Visual Studio (and beyond). Microsoft, together with the EditorConfig community, added support for it in Visual Studio and continues to expand the format, including the code style parameters specific to the .NET environment.

EditorConfig and .NET Code Style

Developers have the ability to globally customize their personal preferences for writing code in Visual Studio through the Tools> Options menu. Now, in VS 2017, you can customize your coding conventions in the EditorConfig file, and any violations of the rules immediately get into the editor as you type. This means that now, regardless of which side you are in the code style debate, you can choose the agreements that you think are best for any part of your codebase — be it a whole solution or only some legacy section for which you do not want to change these conventions. To demonstrate some of the features of this functionality, you can take a look at the changes that were made to use EditorConfig in the Roslyn repository.

Beginning of work

Roslyn takes full advantage of the style described in the .NET Foundation Coding Guidelines . Setting rules in the EditorConfig file will allow developers to track violations of their encoding rules as they are entered, and not during the code review process.
')
To determine the code style and formatting options for the entire repository, simply add the .editorconfig file to the top level directory. To set these rules as “root” parameters, add the following to .editorconfig (you can do this in your own / IDE editor):

# top-most EditorConfig file
root = true

EditorConfig parameters are applied from top to bottom with overrides, that is, you describe the general rules at the top and override them further down in your directory tree as necessary. In the Roslyn repository, the files in the Compilers directory do not use var, so we can simply create another .editorconfig file that contains different settings for the var preferences, and these rules will only apply to files in that directory. Note that when we create this EditorConfig file in the Compilers directory, we don’t need to add root = true (this will allow you to inherit the rules from the parent directory or, in this case, from the top-level Roslyn directory).

Code Formatting Rules

Now that we have EditorConfig files in our directories, we can begin to define some rules. There are eight formatting rules that are usually supported through EditorConfig in editors and IDEs: charset, indent_style, indent_size, tab_width, end_of_line, trim_trailing_whitespace, insert_final_newline and max_line_length . Starting with VS 2017, only the first five formatting rules are supported. To add a formatting rule, specify the file type (s) to which you want to apply the rule, and then define your own rules, for example:

# Code files
[*.cs,*.csx,*.vb,*.vbx]
indent_size = 4


Code Style Rules

After collaborating with the EditorConfig community, the file format was expanded to support the style of the .NET code. The set of coding conventions has also been expanded, which can be configured and applied to include rules such as preference for collection initializers , expression-bodied members , C # 7 pattern matching, and more!

Let's look at an example of how coding conventions can be defined:

# CSharp code style settings:
[*.cs]
csharp_style_var_for_built_in_types = true : none
csharp_style_var_elsewhere = true : error
csharp_style_expression_bodied_methods = false : suggestion
csharp_style_throw_expression = true : warning

The left side is the name of the rule, the right side indicates the rule settings: preference level and execution level, respectively.

• Preference settings can be either true (meaning “use this rule”) or false (which means “do not use this rule”).
• The execution level is the same for all Roslyn based code analysis and can be from the least serious to the most serious: none , suggestion , warning or error .

Ultimately, your build will fail if you break a rule that is enforced at the severity level of the error. To see all the code style rules available in VS 2017, and the final Roslyn code style rules, see Roslyn .editorconfig or read the documentation .

If you need to rethink the different levels of severity and what they do:



Tip: The gray dots that indicate the sentence are rather gray. To diversify your life, try changing them to a nice pink. To do this, go to Tools> Options> Environment> Fonts and Colors> Suggestion ellipses (...) and set the parameter to the following custom color (R: 255, G: 136, B: 196):

Experience in Visual Studio

When you add an EditorConfig file to an existing repository or project, the files are not automatically checked to match your conventions. When you add or edit an EditorConfig file to apply the new settings, you must close and open all open files that you have. To ensure that the entire document adheres to the code formatting rules defined in your preferences, you can use the Format Document (Ctrl + K, D). This check does not change the code, but you can use the quick action menu (Ctrl +.) To apply the code style fix to all entries in the document / project / solution.



Tip: To check that your document uses spaces or tabs, turn on Edit> Advanced> View White Space .

But how do you know if an EditorConfig file is applied to your document? You can take a look at the lower status bar in Visual Studio and see this message:



Note that this means that the EditorConfig files override any code style settings that you have configured in the Tools> Options menu.

To get support for language services when editing the EditorConfig file in VS, download the EditorConfig Language Service extension.

Conclusion

Visual Studio 2017 is just a step in the configuration agreement for writing code. To learn more about the support for EditorConfig in Visual Studio 2017, read the documentation.

Thanks for attention!