Visual Studio IntelliCode now infers coding conventions for consistent code

Following the initial announcement of Visual Studio IntelliCode at Build 2018, we’re excited to report that the Visual Studio IntelliCode Extension has been updated to enable coding convention inference for C#, to help you and your team achieve more readable and consistent code. If you’re new to the Intellicode extension, it already provides AI-assisted IntelliSense suggestions, which you can read about in the initial announcement. If you already have the extension installed, you may have automatically received this update. If not, you can get started now by downloading the extension.

Inferring code style and formatting conventions for your codebase

Inferring code style and formatting conventions for your codebase

Consistency is important for code maintainability and readability; in fact, a recent Microsoft Research study in this area showed that 18 percent of pull request review comments were related to coding conventions, styles, and naming issues.  

With this update, the IntelliCode extension can now generate an .editorconfig file on-demand that best matches the coding conventions used in your codebase; no more long discussions with your team about the best convention to use! Once generated, this file will help you maintain consistency in your team’s codebase. Fixing up formatting issues is quick and easy with the Quick Action lightbulb menu (Ctrl+. or Alt+Enter) or with the new configurable Format Document (Ctrl+K, D) in Visual Studio 2017 version 15.8 Preview 3 and higher. 

How to use .editorconfig inference

IntelliCode creates the inferred .editorconfig file by scanning the code files below your chosen location to create the best matching set of conventions. Once it’s there, you will see any coding convention violations related to style show up in the error list as Messages as illustrated below:

Coding convention violations related to style show up in the error list as Messages

The style violations are set up to default to “Message” severity – this is shown by the “:suggestion” suffix on each rule line in the .editorconfig file .You can tweak the file if you want a different level of enforcement, like warning or error.  Note that formatting violations do not show up in the Error List,  but can still be fixed easily – see our “how to” below.

You can invoke EditorConfig generation via the Solution Explorer. Simply right-click on the solution, project, or folder level folder where you want the conventions to apply, select “add”, and then “EditorConfig file (IntelliCode)”. For projects you can also select “add” then “new item” then “EditorConfig file (IntelliCode)”. Note that EditorConfig files apply enforcement hierarchically to all files below it in the filesystem “cone”. For instance, if you want a set of conventions that apply to your whole solution, place your .editorconfig in the solution directory. If you have subfolders or projects that have different conventions, you can create a new EditorConfig for those subfolders/projects to override the conventions from the higher level.

How to fix up your code to conform to the new conventions

There are a couple of ways to clean up your code to conform to the new conventions, depending on your goals.

  1. Using Quick Actions Lightbulb Menu (Ctrl+. or Alt+Enter)
    For style issues, lightbulbs will appear (along with error list entries), to allow you to auto-fix any inconsistencies. You can choose the scope of the fix in the lightbulb – instance, document, project or solution.
  1. Using Format Document (Ctrl+K,D)
    For both format and style issues, if you are using Visual Studio 2017 15.8 Preview 3 or higher, you’ll be able to use the extended “Format Document” command to perform additional code cleanup for the current document. This will fix up the code in that document to conform to the conventions you just created, allowing you to adopt a “clean up as you touch each file” approach to getting consistent. Note that this additional capability in format document only covers a fixed set of issues, which you can change in Tools > Options > Text Editor > C# > Code Style > Formatting > General > Format Document Settings (Experiment):Format Document Options Extension For Conventions

Notice that the default settings do not fix some style conventions. You can opt in to these via tools options (e.g. Apply implicit/explicit type preferences will run style rules related to the use of var in your code).

Things to be aware of when using EditorConfig inference

There are a couple of known issues to be aware of when using EditorConfig inference:

  1. You need to close and reopen open files to see changes to the conventions apply in 15.8 Preview 2 and earlier
    In Visual Studio 2017 versions prior to 15.8 Preview 3, you will need to close and re-open all open documents to see the conventions in the EditorConfig file you create take effect. This is fixed in the 15.8 Preview 3 release.
  1. Creating through the File-New Item dialog adds a “1” To the filename
    If you use the File-New Item dialog route to create your EditorConfig, in Visual Studio versions prior to 15.8 Preview 4, you’ll need to manually remove the superfluous “1” Prefixing the EditorConfig file name in the dialog. This is fixed in the 15.8 Preview 4 release.

Thanks for all your interest in IntelliCode. We’re excited to hear your feedback and improve IntelliCode as we make more progress. Use the extension’s review page to make suggestions; if you find any problems with the extension, please use the built-in Visual Studio “Report a Problem” option, and mention IntelliCode in your report – reporting this way helps us gather helpful information to resolve the issue.

Get Involved

As we expand capabilities to more scenarios and other languages, we’ll announce a limited preview of IntelliCode.

Sign up to become an insider to keep up with the project and join the waitlist for the private preview.

Thanks!

Mark Wilson-Thomas, Senior Program Manager, Visual Studio IDE Team
@MarkPavWT

Mark is a Program Manager on the Visual Studio IDE team, where he’s been building developer tools for nearly 10 years. He currently looks after the Visual Studio Editor. Prior to that, he worked on tools for Office, SQL, WPF and Silverlight.