Если над проектом работает команда из нескольких человек, то она неизбежно сталкивается с проблемой стиля кодирования. Кто-то скобки расставил по-своему, кому-то больше нравится 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
:

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