Настройка editorconfig visual studio

Обновлено: 22.01.2025

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

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

EditorConfig

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

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

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

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

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

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

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

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

Правила

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

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

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

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

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

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

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

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

Если в .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 :

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

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

Visual Studio 2017 обеспечивает соблюдение стиля написания кода и поддержку EditorConfig. Новая версия включает в себя больше правил для code style и позволяет разработчикам настраивать стиль кода через EditorConfig.

Что такое EditorConfig?

EditorConfig — это формат файла с открытым исходным кодом, который помогает разработчикам настраивать и применять правила форматирования и соглашения о стиле написания кода для получения более читаемых кодовых баз (codebases). Файлы EditorConfig легко включаются в систему управления версиями и применяются на уровне репозитория и проекта. Соглашения EditorConfig переопределяют их эквиваленты в ваших личных настройках, так что соглашения из кодовой базы имеют приоритет над индивидуальным разработчиком.

Разработчики имеют возможность глобально настроить свои личные предпочтения для стиля написания кода в Visual Studio через меню Tools > Options. Теперь, в VS 2017 вы можете настроить свои соглашения о кодировании в файле EditorConfig, и любые нарушения правил сразу же попадают в редактор по мере ввода. Это означает, что теперь, независимо от того, на какой стороне вы находитесь в дебатах по code style, вы можете выбрать, те соглашения, которые, по вашему мнению, наилучшим образом подходят для любой части вашей кодовой базы — будь то целый solution или только некий legacy раздел, для которого вы не хотите изменять эти соглашения. Чтобы продемонстрировать некоторые особенности этой функциональности, можно взглянуть на изменения которые были сделаны для использования EditorConfig в репозиторие Roslyn

Начало работы

Чтобы определить стиль кода и параметры форматирования для всего репозитория, просто добавьте файл .editorconfig в каталог верхнего уровня. Чтобы установить эти правила в качестве «корневых» параметров, добавьте следующее в .editorconfig (вы можете сделать это в своем редакторе / IDE по выбору):

Правила форматирования кода

Правила стиля кода

Давайте рассмотрим пример того, как могут быть определены соглашения о кодировании:

Настройки предпочтений могут быть либо true(означать, «использовать это правило»), либо false (что означает «не использовать это правило»).
Уровень выполнения одинаковый для всего анализа кода на основе Roslyn и может быть от наименьшей серьезности до самого серьезного: none, suggestion, warning или error.

Если вам нужно переосмыслить различные уровни серьезности и то, что они делают:

Совет: серые точки, которые указывают на предложение, довольно серые. Чтобы разнообразить вашу жизнь, попробуйте изменить их на приятный розовый. Для этого перейдите в меню Tools > Options > Environment > Fonts and Colors > Suggestion ellipses (…) и задайте для параметра следующий настраиваемый цвет (R: 255, G: 136, B: 196):

Опыт работы в Visual Studio

Когда вы добавляете файл EditorConfig к существующему репозиторию или проекту, файлы не проверяются автоматически, чтобы соответствовать вашим соглашениям. Когда вы добавляете или редактируете EditorConfig файл, чтобы применить новые настройки, вы должны закрыть и открыть все открытые файлы, которые у вас есть. Чтобы весь документ придерживался правил форматирования кода, определенных в ваших настройках, вы можете использовать Format Document (Ctrl + K, D). Эта проверка не изменяет код, но вы можете использовать меню быстрых действий (Ctrl +.), чтобы применить исправление стиля кода ко всем вхождениям в документе/проекте/решении.

Совет: Чтобы проверить, что в вашем документе используются пробелы или табуляции, включите Edit > Advanced > View White Space.

Обратите внимание, что это означает, что EditorConfig файлы переопределяют любые настройки стиля кода, которые вы настроили в меню Tools > Options.

Чтобы получить поддержку языковых служб при редактировании EditorConfig файла в VS, загрузите расширение EditorConfig Language Service.

Вывод

Visual Studio 2017 — просто ступенька в конфигурации соглашения о написания кода. Чтобы узнать больше о поддержке EditorConfig в Visual Studio 2017, ознакомьтесь с документацией.

В проект или базу кода можно добавить файл EditorConfig, чтобы обеспечить использование единообразного стиля написания кода всеми разработчиками, работающими с базой кода. Параметры EditorConfig имеют приоритет над глобальными параметрами текстового редактора Visual Studio. Это означает, что каждую базу кода можно настроить для использования параметров текстового редактора, относящихся к конкретному проекту. Вы по-прежнему можете задать личные настройки редактора в диалоговом окне Параметры среды Visual Studio. Эти параметры применяются при работе с базой кода, в которой нет файла EDITORCONFIG, или если файл EDITORCONFIG не переопределяет тот или иной параметр. Примером такой настройки может служить стиль отступов: символы табуляции или пробелы.

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

При добавлении файла EditorConfig в проект в Visual Studio новые строки кода форматируются в соответствии с параметрами в файле EditorConfig. Форматирование существующего кода изменяется только при выполнении одной из следующих команд:

команда Очистка кода (CTRL+K, CTRL+E), которая применяет параметры пробелов, например стиль отступов, и выбранные параметры стиля кода, например способ сортировки директив using ;
команда Правка > Дополнительно > Форматировать документ (или CTRL+K, CTRL+D в профиле по умолчанию), которая применяет только параметры пробелов, например стиль отступов.

При добавлении файла EditorConfig в проект в Visual Studio новые строки кода форматируются в соответствии с параметрами в файле EditorConfig. Форматирование имеющегося кода не изменяется, если не отформатировать документ (Правка > Дополнительно > Форматировать документ или клавиши CTRL+K, CTRL+D в профиле по умолчанию). Форматирование документа влияет только на параметры пробелов, например на стиль отступов, если только вы не настроили команду "Форматировать документ" для дополнительной очистки кода.

Вы можете выбрать, какие параметры EditorConfig команда Форматировать документ будет применять к странице параметров форматирования.

Этот раздел относится к Visual Studio в Windows. Информацию о Visual Studio для Mac см. в статье EditorConfig в Visual Studio для Mac.

Согласованность кода

Соглашения для кодирования, используемые вами в личных проектах, могут отличаться от тех, которые действуют в командных проектах. Например, вы предпочитаете, чтобы при вставке отступа во время написания кода добавлялся символ табуляции. Однако в команде может быть принято, чтобы при отступе вместо символа табуляции добавлялись четыре символа пробела. Файлы EditorConfig устраняют эту проблему, позволяя создавать конфигурацию для каждого сценария.

Соглашения, заданные в файле EditorConfig, в настоящее время не могут быть реализованы в конвейере CI/CD с созданием ошибки или предупреждения. Все отклонения от стиля видны только в редакторе Visual Studio и списке ошибок.

Поддерживаемые параметры

Редактор в Visual Studio поддерживает основной набор свойств EditorConfig:

indent_style
indent_size
tab_width
end_of_line
charset
trim_trailing_whitespace
insert_final_newline
корневой

Добавление и удаление файлов EditorConfig

При добавлении файла EditorConfig в проект или базу кода, все новые строки создаваемого кода форматируются в соответствии с параметрами в файле EditorConfig. Но само по себе добавление файла EditorConfig не приводит к преобразованию существующих стилей в новые, пока вы не запустите форматирование документа или очистку кода. Например, если в качестве отступов в файле используются символы табуляции, при добавлении файла EditorConfig, в котором отступы задаются пробелами, символы отступа не преобразовываются в пробелы автоматически. При форматировании документа (Правка > Дополнительно > Форматировать документ или клавиши CTRL+K, CTRL+D) параметры пробелов в файле EditorConfig применяются к имеющимся строкам кода.

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

Добавление файла EditorConfig в проект

Откройте проект или решение в Visual Studio. Выберите узел проекта или решения в зависимости от того, следует ли применять настройки файла EDITORCONFIG ко всем проектам в решении или только к одному. В проекте или решении также можно выбрать папку, в которую будет добавлен файл EDITORCONFIG.

В строке меню выберите Проект > Добавить новый элемент либо нажмите сочетание клавиш CTRL+SHIFT+A.

Откроется диалоговое окно Добавление нового элемента.

В поле поиска введите строку editorconfig.

В результатах поиска отобразятся два шаблона элементов для файла editorconfig.

В обозревателе решений появится файл EDITORCONFIG, который откроется в редакторе.

Измените файл по своему усмотрению.

Другие способы добавления файла EditorConfig

Существует несколько способов добавления в проект файла EditorConfig:

Функция определения кода IntelliCode для Visual Studio позволяет настроить стили кода по существующему коду. Она создает непустой файл EditorConfig с определенными параметрами для вашего стиля кода.

Начиная с Visual Studio 2019 вы можете создать файл EditorConfig для настроенных параметров стиля кода через пункт меню Средства > Параметры.

Иерархия и приоритет файлов

При добавлении файла EDITORCONFIG в папку в иерархии файлов его параметры применяются ко всем соответствующим файлам на этом уровне и ниже. Можно также переопределить параметры EditorConfig для конкретного проекта, базы кода или части кода так, чтобы использовать другие соглашения, чем в остальных частях базы кода. Это может быть полезно при включении кода из-каких либо еще мест без изменения его соглашений.

Чтобы переопределить некоторые или все параметры EditorConfig, добавьте файл EDITORCONFIG на уровне иерархии файлов, к которой следует применить эти переопределенные параметры. Новые параметры в файле EditorConfig будут применяться к файлам того же уровня и к файлам во всех подкаталогах.

Если необходимо переопределить только некоторые параметры, просто укажите их в файле EDITORCONFIG. Переопределяются только те свойства, которые явно перечислены в файле более низкого уровня. Другие параметры из файлов EDITORCONFIG более высокого уровня будут применяться по-прежнему. Чтобы к этой части базы кода не применялись параметры из любых файлов EDITORCONFIG более высокого уровня, добавьте свойство root=true в файл EDITORCONFIG более низкого уровня:

Файлы EditorConfig считываются сверху вниз. При наличии множества свойств с одним именем приоритет будет иметь последнее обнаруженное свойство с таким именем.

Изменение файлов EditorConfig

Visual Studio позволяет редактировать файлы EDITORCONFIG, предоставляя списки завершения IntelliSense.

После того как вы закончили редактировать файл EditorConfig, необходимо повторно загрузить файлы кода, чтобы новые параметры вступили в силу.

При редактировании большого количества файлов EDITORCONFIG может быть полезным расширение языковой службы EditorConfig. В число возможностей этого расширения входят выделение синтаксиса, улучшенная технология IntelliSense, функции проверки и форматирования кода.

Пример

Как и ожидалось, при нажатии клавиши TAB в следующей строке создается отступ путем добавления еще четырех символов пробела.

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

Устранение неполадок параметров EditorConfig

"Пользовательские предпочтения для этого типа файлов переопределены рекомендациями по написанию кода этого проекта".

Это означает, что, если какие-либо параметры редактора из раздела Инструменты > Параметры > Текстовый редактор (например, размер и стиль отступа, размер интервала табуляции или соглашения о кодировании) заданы в файле EditorConfig, находящемся в структуре каталогов в папке проекта или выше, соглашения в этом файле переопределяют значения в окне Параметры. Управлять этим поведением можно с помощью параметра Следовать рекомендациям по написанию кода проекта в разделе Инструменты > Параметры > Текстовый редактор. Если снять этот флажок, поддержка EditorConfig в Visual Studio будет отключена.

Чтобы найти файлы с расширением .editorconfig в родительских каталогах, откройте командную строку и выполните следующую команду из корня диска, на котором находится проект:

Управлять областью действия соглашений EditorConfig можно с помощью свойства root=true в файле EDITORCONFIG, который находится в корне репозитория или в каталоге, где размещается проект. В Visual Studio поиск файла EDITORCONFIG выполняется в каталоге, где находится открытый файл, и во всех его родительских каталогах. Поиск завершается по достижении корня пути к файлу или при нахождении файла EDITORCONFIG с root=true .

Так может выглядеть интерфейс редактора после установки расширений

Основные возможности

отладчик кода
встроенный терминал
удобные инструменты для работы с Git
подсветка синтаксиса для множества популярных языков и файловых форматов
удобная навигация
встроенный предпросмотр Markdown
умное автодополнение
встроенный пакетный менеджер

VS Code имеет большое количество расширений для разработчика. Для установки нового пакета зайдите во вкладку “Extensions”, введите название пакета в строке поиска, нажмите кнопку “Install”.

EditorConfig for VS Code

EditorConfig — это конфигурационный файл и набор расширений к большому количеству редакторов кода. Он подхватывает настройки из файла .editorconfig , который, как правило, размещается в корне проекта. Расширение автоматически настроит отступы и перевод строк единообразно для всех разработчиков, использующих его. PHP код чаще всего выполняется на *nix системах, поэтому необходимо использовать стандарт.

Ниже приводится пример файла .editorconfig , который используется в Laravel:

PHP Intelephense

В редакторе уже есть поддержка синтаксиса и подсказок стандартных функций языка. Но без специального дополнения редактор не будет подсказывать пользовательские функции из других частей проекта. Поэтому для поддержки автодополнения, анализа кода, перехода к месту, где создана функция/класс/переменная (с помощью шортката Alt+Click ), используется дополнение PHP Intelephense

Чтобы подсказки не дублировались необходимо отключить встроенную в редактор поддержку кода для PHP: Extensions -> Search @builtin php -> PHP Language Features -> Disable

PHP Debug

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

Чтобы воспользоваться PHP Debug, необходимо установить сам XDebug, без него расширение для редактора работать не будет. Установив расширение, необходимо добавить конфигурацию для PHP в разделе Debug . После выбора языка в корне проекта будет создан файл .vscode/launch.json с задачами для Дебаггера. Расширение создаст файл со стандартными параметрами.

Для того, чтобы XDebug общался с нашим дебаггером, необходимо добавить настройки в файл конфигурации php. Чтобы найти этот файл выполните в терминале команду php --ini или запустите веб-сервер с кодом phpinfo() .

В Linux PHP подгружает не только основной файл, но и файл из этой директории. Например, на Ubuntu путь к директории конфигурационных файлов для PHP может быть таким — /etc/php/7.3/cli/conf.d/ . В ней создаём файл с необходимыми правами (требуются root права):

Это настройки для локальной разработки, когда проект разрабатывается и запускается на одном компьютере, например на вашей рабочей машине

PHP Sniffer

В языках программирования есть понятие стиль кодирования. Но не все разработчики знают об этом. Программа, которая отвечает за проверку на соответствие стандартам, называется линтер. В PHP приняты стандарты под названием PSR. Нас интересуют стандарты PSR-1 и PSR-12. Именно эти два стандарта касаются кодирования и правил оформления.

В PHP в качестве линтера используется PHP_CodeSniffer. Для его работы необходимо установить глобально сам линтер composer global require "squizlabs/php_codesniffer=*" и расширение PHP Sniffer.

Проверьте, что линтер установился:

Выполнить проверку кода в терминале можно с помощью команды phpcs , явно указав стандарт, который мы хотим использовать, и путь для проверки:

Semicolon Insertion Shortcut

PHP требует разделять инструкции с помощью точки запятой. Расширение Semicolon Insertion Shortcut добавляет необходимый символ в конец строки с помощью шортката. Если при нажатии [Ctrl] + ; символ не вставляется, то необходимо проверить список горячих клавиш и при необходимости назначить комбинацию вручную: File -> Preferences -> Keyboard Shortcuts

Extra

Список расширений, которые могут быть использованы не только для PHP:

— в VS Code уже встроена поддержка Git. Но когда базовых возможностей становится недостаточно, на помощь может придти Gitlens. Например, одна из полезных фич — git blame на текущей строке.

— разноцветные отступы в коде. Подсвечивает некорректный отступ. Можно вместо радуги установить оттенки серого.

Settings Sync — плагин, позволяющий синхронизировать настройки редактора между разными компьютерами. В качестве облачного хранилища используется Github Gists. Все настройки можно скачать, указав нужный файл синхронизации.

Fira Code — моноширинный шрифт, в котором используются лигатуры (объединяет несколько символов в один) для общих комбинаций символов в программировании. Визуальная надстройка для более удобного чтения кода.

Перевод статьи «Why You Should Use EditorConfig to Standardize Code Styles».

Вы используете EditorConfig для определения соглашений по форматированию файлов в проекте? Прекрасно! Он имеет широкую поддержку, не привязан ни к какому языку программирования, фреймворку или редактору.

Файлы EditorConfig читаются IDE (интегрированными средами разработки), редакторами кода и инструментами сборки, которые и обеспечивают применение нужных стилей.

Какие проблемы решает EditorConfig?

Обычно разработчики настраивают стили кода в редакторе в соответствии с собственными предпочтениями. К сожалению, их предпочтения могут не совпадать с вашими.

Что происходит, когда много разных людей с разными предпочтениями являются контрибьюторами одного проекта? Речь может идти о проекте на вашей работе или же open-source проекте на GitLab или GitHub.

К файлам, с которыми работают контрибьюторы, применяются их собственные настройки стилей. В результате проекты могут стать непоследовательными и неряшливыми. В них могут появиться следующие проблемы:

смесь табов и пробелов
разные символы перевода строки (обычно при использовании Git это не является существенной проблемой)
файлы могут не иметь желаемой кодировки символов
в разных файлах могут быть разные размеры отступов

Когда код непоследователен, он кажется неопрятным и его тяжело читать (это еще зависит от среды разработки).

eclipse.jdt.ls со смешанными табами и пробелами. Вид в GitHub с tab size = 8

Только для разработки на Java у нас на выбор несколько вариантов редакторов и IDE:

Если добавлять файлы конфигурации для всех редакторов, которые кто-то может использовать, это лишь напрасно раздует проект.

Как насчет универсального решения, при котором ответственность за использование общей конфигурации лежит на самом редакторе?

Чем полезен EditorConfig

Общие соглашения относительно стиля кода играют большую роль в проекте. Они помогают существенно экономить время благодаря следующим аспектам их использования.

EditorConfig делает код более читаемым

Но ваш код могут читать не только разработчики, создающие проект. Это могут быть:

исследователи, которым нужно более детально разобраться в работе проекта
аналитики безопасности, проверяющие проект на уязвимости
технические писатели, документирующие поведение программы.

Если ваш код будет чистым, последовательным и человекочитаемым, все эти люди смогут более эффективно выполнять свою работу.

EditorConfig облегчает код-ревью

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

Ускорение цикла обратной связи очень сильно экономит время всем участникам процесса.

EditorConfig облегчает разработку

Наличие соглашений о стиле кода и автоматическое применение правил редактором избавляет разработчиков от лишней головной боли.

Без всего этого им пришлось бы самостоятельно разыскивать руководство по стилю и руководство для контрибьюторов, а потом вручную проверять код на соответствие соглашениям.

И даже если правила соглашений всем известны, они могут конфликтовать с настройками редактора у разработчика. В таком случае ему придется писать код, не соответствующий автоматическому форматированию в редакторе, либо менять настройки редактора.

Это имеет особое значение для программистов, часто меняющих проекты. Например, open-source контрибьюторы часто пишут код для проектов разных организаций, в которых придерживаются разных соглашений.

Как работает EditorConfig

EditorConfig использует простой .ini-подобный файл с именем .editorconfig. Этот файл объявляет правила, которые будут отражаться на настройках вашего редактора либо осуществлять форматирование поверх вашего рабочего пространства.

Например, в своем редакторе я использую для XML-файлов отступы в два пробела, но в проекте, где я выступаю контрибьютором, применяются 4-пробельные отступы.

Раздел файла .editorconfig, указывающий, что XML-файлы должны иметь отступы в 4 пробела:

Когда я открываю проект, мой редактор видит файл .editorconfig и перезаписывает настройки, чтобы они соответствовали соглашениям проекта.

Написание XML-файла с моими дефолтными настройками редактора. Я использую отступы в 2 пробела.

Автоматическое переформатирование файла после перезаписи настроек, касающихся XML-файлов.

Как использовать EditorConfig

Возможно, ваш редактор уже поддерживает EditorConfig. Проверить, входит ли он в список редакторов с нативной поддержкой EditorConfig, можно на странице «No Plugin Necessary». IDE от JetBrains и Visual Studio в списке есть.

После установки редактор должен автоматически находить файл .editorconfig в проекте (если он там есть, конечно) и применять правила из этого файла.

Как определять правила в EditorConfig

Список правил можно найти на Вики-странице EditorConfig. Там есть все официально поддерживаемые правила, а также предложения правил, относящихся к определенным доменам. Эти последние могут поддерживаться некоторыми реализациями.

В файле EditorConfig верхнего уровня (обычно верхнеуровневый конфиг будет в корне вашего проекта) нужно установить root = true.

Во вложенных директориях могут быть свои файлы EditorConfig, но для них root = true не устанавливается.

Затем можно определить заголовок, где указываются файлы, для которых должны применяться следующие ниже правила.

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

Определение правил для каждого отдельного проекта

Просто добавляйте .editorconfig, когда он вам нужен. Например, можно определять правила или добавлять форматы файлов по мере роста проекта.

Начальный файл .editorconfig может быть сгенерирован вашим редактором или создан вручную. Содержимое можно скопировать в примере на официальном сайте.

Определение правил для всех проектов

Или же вы можете собрать все свои предпочтения воедино и спланировать идеальную конфигурацию для всех файлов, с которыми вам может случиться работать.

Начать можно с нуля, а можно скопировать мой вариант и внести нужные изменения.

Файл .editorconfig, который я использую во всех проектах, которые поддерживаю:

Заключение

Благодаря этому мейнтейнеры смогут просматривать пул-реквесты, соответствующие установленным стилевым правилам, а редактор кода (IDE) будет автоматически применять эти правила.

Людям, работающим над проектом, тоже будет проще. Благодаря перезаписи настроек разработчики смогут писать код так, как удобно им самим, и не заморачиваться с ручной заменой настроек для каждого проекта.

Ваши проекты станут чище, поскольку все правила будут прописаны в одном «независимом» файле, а не в файлах разных редакторов кода.

Читайте также: