Если над проектом работает команда из нескольких человек, то она неизбежно сталкивается с проблемой стиля кодирования. Кто-то скобки расставил по-своему, кому-то больше нравится var вместо указания явного типа, кому-то — наоборот. Чего уж там говорить про open-source проекты, где случайный прохожий может сделать баг-фикс и уйти. Всё это ведет к тому, что стиль кода в проекте сильно разнится в разных его частях.

EditorConfig — это проект, который помогает разработчикам соблюдать единый стиль кода в рамках всего проекта. Visual Studio 2017 — одна из множества сред разработки, которая имеет встроенную поддержку EditorConfig.

EditorConfig

Проект EditorConfig можно разделить на две части — формат файла, описывающий правила оформления кода и плагины для среды разработки, которые помогают эти правила соблюдать.

Практически все современные среды разработки имеют либо встроенные средства для поддержки EditorConfig, либо поддерживают EditorConfig за счёт устанавливаемых плагинов:

Чтобы добавить правила для стиля кода, достаточно положить файл .editorconfig в корневую папку вашего проекта. При этом можно изменять эти правила в отдельных подпапках — для этого создаем дополнительный файл .editorconfig в нужной подпапке. Т.е. правила EditorConfig применяются иерархически.

Формат файла .editorconfig напоминает INI-файлы с немного расширванным синтаксисом.

Для корневого файла .editorconfig в самом начале нужно добавить root = true. Символы # и ; позволяют добавить комментарии в файл. Превоначальная заготовка выглядит так:

# Правила EditorConfig для
# описания стиля кодирования

root = true

Далее следует описание правил. Но перед этим необходимо определить типы файлов, к которым эти правила должны применяться. Типы файлов задаются в стиле INI-секции:

root = true

[*]
indent_style = space
indent_size = 2

[*.cs]
indent_size = 4

Как видно, правила для всех файлов задаются в секции [*].

Указать типы файлов можно при помощи специальных шаблонов, при написании которых действуют следующие правила:

• * — означает множество любых символов, кроме /
• ** — означает множество любых символов, включая /
• ? — означает любой единственный символ
• [name] — явно задает имя файла
• [!name] — применяется ко всем файлам, кроме указанного
• {s1,s2,s3} — применяется ко всем файлам, указанным в списке
• {x..y} — позволяет задать целочисленный диапазон

Вот некоторые примеры описания типа файлов:

• [*.cs] — все файлы с расширением cs
• [*.{cs,vb}] — все файлы с расширением cs и vb
• [Properties/AssemblyInfo.cs] — файл AssemblyInfo.cs из папки Properties
• [Model/**.js] — все файлы .js из папки Model, включая подпапки
• [{appsettings.json, appsettings.dev.json, appsettings.test.json}] — файлы из списка

Правила

Для каждой секции нужно задать правила. Правила зависят от того, для какого языка программирования вы их пишете.

Правила задаются в следующем формате:

<имя правила> = <значение>

Для C# также можно задавать степень важности правила:

<имя правила> = <значение> : <важность правила>

Задание уровня важности правила позволяет повлиять на поведение компилятора и среды разработки при нарушении правила. Уровень важности может принимать следующие значения:

• none — нет никакой реакции, если правило было нарушено.
• suggestion — при нарушении правила в момент сборки проекта появляется рекомендация во вкладке Messages в Error List.
• warning — при нарушении правила в момент сборки проекта появляется ошибка во вкладке Warnings в Error List. В этом случае сборка останавливается, если установлена опция Treat Warnings as Errors.
• error — при нарушении правила в момент сборки проекта появляется ошибка во вкладке Errors в Error List и сборка останавливается.

Например, для правила:

[*.cs]
csharp_style_var_for_built_in_types = false:warning

Мы увидим только предупреждение в момент сборки, если правило было нарушено.

Но если правило изменить так:

[*.cs]
csharp_style_var_for_built_in_types = false:error

То вы не сможете собрать проект, пока ошибка не будет исправлена.

Список наиболее популярных правил можно найти здесь. Для .NET список правил здесь. В качестве примера .editorconfig для .NET можно посмотреть файл команды Roslyn.

Создадим правила для проекта .NET:

root = true

[*]
# Использовать отсутпы для пробелов
indent_style = space

# Использовать 4 пробела для отступа
indent_size = 4

# Использовать UTF-8 для всех файлов
charset = utf-8

# Запретить пробелы в конце строки
trim_trailing_whitespace = false

# Запретить пустую строку в конце файла
insert_final_newline = false

[*.cs]
# Использовать явное указание простых типов
csharp_style_var_for_built_in_types = false:warning

# Использовать var когда тип очевиден исходя
# из правой части выражения
csharp_style_var_when_type_is_apparent = true:warning

# Во всех остальный случаях также использовать var
csharp_style_var_elsewhere = true:warning

# Новая строка перед открывающей скобкой
csharp_new_line_before_open_brace = true:error

# Новая строка перед членами в анонимных типах
csharp_new_line_before_members_in_anonymous_types = true:warning

Если в .editorconfig не указано какое-либо из правил, то считается, что нужно использовать текущие настройки среды разработки.

Visual Studio

Visual Studio 2017 имеет встроенную поддержку EditorConfig, т.е. вы просто можете добавить файл .editorconfig в проект и пользоваться этим инструментом. Для более ранних версий Visual Studio можно воспользоваться расширением EditorConfig.

Важно! Настройки .editorconfig имеют приоритет над настройками среды разработки.
Это означает, что если у вас в Visual Studio, например, установлен отступ в 4 символа, а в .editorconfig — два, то среда разработки будет считать, что актуальная настройка — два символа.

При подключении .editorconfig к проекту Visual Studio автоматически подхватит эти настройки. Теперь если вы отформатируете документ при помощи меню Edit → Advanced → Format Document или Ctrl + e, D, то документ будет отформатирован в соответствии с правилами .editorconfig:

Если при сборке проекта какое-то правило нарушено, то вы увидите об этом ошибку: