Editorconfig for vs code как пользоваться

Создание и редактирование пользовательского файла EditorConfig в Visual Studio для Mac

Visual Studio для Mac планируется выйти на пенсию 31 августа 2024 года в соответствии с современной политикой жизненного цикла Майкрософт. Хотя вы можете продолжать работать с Visual Studio для Mac, есть несколько других вариантов для разработчиков на Mac, таких как предварительная версия нового расширения комплекта разработки C# для VS Code.

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

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

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

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

• indent_style
• indent_size
• tab_width
• end_of_line
• charset
• trim_trailing_whitespace
• insert_final_newline
• root

Кроме того, EditorConfig поддерживает соглашения о написании кода в C#.

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

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

1. Откройте проект в Visual Studio для Mac. Выберите решение или узел проекта, в который нужно добавить файл EditorConfig. При добавлении файла в каталог решения параметры .editorconfig применяются ко всем проектам в решении.
2. Щелкните узел правой кнопкой мыши и выберите команду Добавить > Новый файл, чтобы открыть диалоговое окно Новый файл.
3. Выберите Прочее > Пустой текстовый файл и присвойте ему имя .editorconfig . Нажмите клавишу Создать для создания файла и откройте его в редакторе: Когда элемент добавляется на уровне решения, он автоматически создается и помещается в папку Элементы решения:
4. Измените файл . Например:

# This file is the top-most EditorConfig file root = true # All Files [*] indent_style = space indent_size = 8 insert_final_newline = false trim_trailing_whitespace = false [*.cs] csharp_new_line_before_open_brace = none 

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

Добавление существующего файла EditorConfig

Если вы работаете с проектом или решением, которое уже содержит файл .editorconfig , то для применения параметров не требуется никаких действий. Все новые строки кода форматируются в соответствии с параметрами, заданными в файле EditorConfig.

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

1. Щелкните папку, которую нужно добавить, правой кнопкой мыши и выберите параметры Добавить > Добавить файлы.
2. Перейдите в каталог, где находится необходимый файл.
3. Файлы, названия которых начинаются с . (например, .editorconfig ), в macOS являются скрытыми, поэтому нажмите клавиши COMMAND + SHIFT + ., чтобы сделать файл .editorconfig видимым.
4. Выберите файл .editorconfig и нажмите Открыть:
5. Когда откроется следующее диалоговое окно, выберите вариант Скопировать файл в каталог и нажмите ОК:

Применение параметров .editorconfig

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

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

Редактирование файла EditorConfig

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

# This file is the top-most EditorConfig file root = true # All Files [*] indent_style = space indent_size = 4 insert_final_newline = false trim_trailing_whitespace = false [*.cs] csharp_new_line_before_open_brace = none 

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

Каждый раздел файла обозначается квадратными скобками ([]) и задает тип файлов, к которым будут применяться параметры данного раздела.

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

До:

После:

Дополнительные сведения о доступных параметрах EditorConfig см. в статье Параметры соглашений о написании кода .NET в EditorConfig и в разделе Supported Properties (Поддерживаемые свойства) официальной документации.

Переопределение параметров EditorConfig

Можно иметь несколько файлов .editorconfig в одном решении. Visual Studio для Mac прочитывает файлы .editorconfig в решении сверху вниз, добавляя и переопределяя параметры в процессе операции. Это означает, что параметры в .editorconfig , ближайшие к файлу, который вы редактируете, имеют приоритет. Параметры берутся из файла .editorconfig , который находится в той же папке (если она существует), затем из файла .editorconfig в родительской папке (если она существует) и т. д., пока не будет найдено значение root=true .

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

# top-most EditorConfig file root = true 

См. также

EditorConfig — Одни Настройки для всех Редакторов/IDE

EditorConfig это конфигурационный файл и набор расширений, к большому количеству редакторов кода и IDE (Далее просто IDE).

Его задача — создать единый формат настроек, и, раз и навсегда, решить вопросы вроде “табы или пробелы” для всех IDE и всех языков программирования. Такой файл может храниться в системе контроля версий проекта, что позволит всем его разработчикам использовать одну и ту же конфигурацию.

Файлы .editorconfig можно найти в таких проектах, как jQuery, Ruby, WordPress, и многих других.

Плагины доступны для большого количество IDE

Давайте разберемся, как это работает.

Как выглядит файл EditorConfig?

Вот пример файла .editorconfig , который задает правила отступа для Python и JavaScript кода:

## Заранее извиняюсь за отсутствие нормальной подсветки синтаксиса в этом примере и далее. ## Хоть "ini" и содержится в списке форматов поддерживаемых Хабром, код красивым не становится. ## Если кто знает, как это починить - пожалуйста напишите в личку. # # Корневой файл EditorConfig root = true # Для всех файлов используем unix-совместимые переносы строк [*] end_of_line = lf insert_final_newline = true # отступы в 4 пробела [*.py] indent_style = space indent_size = 4 # Используем табы для отступов (Не указываем размер) [*.js] indent_style = tab # Перезависываем настройку отступов для js файлов в папке lib [lib/**.js] indent_style = space indent_size = 2 # Только для файлов package.json or .travis.yml [] indent_style = space indent_size = 2 

Формат файла

Файлы EditorConfig используют слегка модифицированный INI формат.
Каждый .editorconfig должен быть в кодировке UTF-8 , а в конце строк должно быть либо
CRLF либо LF .

В качестве имени секции выступает маска файлов, например [*.js] или [index.html] .

В отличии от обычного .ini формата, в имени секции можно использовать [ и ] , что позволяет указать список символов, один из которых должен находиться в указаной позиции. Например, допустимы конструкции вроде этой: [file[123].js] . Как это работает — читайте ниже.

Каждый комментарий должен быть на отдельной строке и начинаться с ; или # .

Как работает поиск файлов по маске

* — Любое количество символов кроме разделителя пути (/)

Пример: [*.js]
hello.js // Совпадение
hellojs // Нет совпадения
index.html // Нет совпадения
lib/source.js // Нет совпадения

** — Любое количество символов

Пример: [**.js]
hello.js // Совпадение
hellojs // Нет совпадения
index.html // Нет совпадения
lib/source.js // Совпадение

? — Один любой символ

Пример: [hell?.js]
hello.js // Совпадение
hell.js // Нет совпадения

[name] — Любой символ из символов содержащийся в “name”

Пример: [[abc].js]
a.js // Совпадение
b.js // Совпадение
abc.js // Нет совпадения

[!name] — Любой символ которого нету в “name”

Пример: [file[!2468].js]
file1.js // Совпадение
file2.js // Нет совпадения

— Любая из строк разделенных запятыми

Пример: [index.]
index.js // Совпадение
index.html // Совпадение
package.json // Нет совпадения

\ — Экранирование служебных символов

Пример: [\[abc\].js]
a.js // Нет совпадения
[abc].js // Совпадение

Настройки

Что можно настроить?

Editor config стремится быть независимым от языков и работать во всех IDE. К сожалению это не всегда возможно, поэтому некоторые из плагинов поддерживают не все настройки. Подробнее можно узнать на странице каждого плагина в гитхабе.

Все настройки нечувствительны к регистру.

indent_style

Значения: tab, space
Позволяет задать жесткую или мягкую табуляцию для отступов.

indent_size

Значения: Число
Позволяет задать ширину отступа использовании мягкой табуляции.

tab_width

Значения: Число
Позволяет задать ширину отступа использовании жесткой табуляции. Если не задано, возьмет значение из indent_size.

end_of_line

Значения: lf, cr, crlf
Позволяет выбрать, что использовать на концах строк.

charset

Значения: latin1, utf-8, utf-8-bom, utf-16be, utf-16le
Позволяет выбрать кодировку для файлов.
Использовать utf-8-bom не рекомендуется

trim_trailing_whitespace

Значения: true, false
Позволяет убрать пробелы из концов строк.

insert_final_newline

Значения: true, false
Позволяет убедиться, что в конце файла всегда будет новая строка.

root

Значения: true, false
Специальная настройка, которая должна быть на самом верху конфига. Если установлена в true, парсер не будет искать другие конфиги родительских папках (Подробности ниже).

Специальное значение Ignore

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

# Задаем форматирование для JS и CSS [*.] indent_style = space indent_size = 2 # Но не переформатируем минифицированные JS и CSS файлы. [*.min.*] indent_style = ignore trim_trailing_whitespace = false insert_final_newline = ignore 

А почему так мало настроек?

Изначальная задача EditorConfig — создать минимальный набор свойств, который работал бы во всех основных IDE.

• Убедиться, что все редакторы/IDE ее поддерживают
• Решить, использовать ли жесткий или мягкий (когда строка физически остается длинной, но выглядит как две) перенос, или позволить пользователю выбрать это, добавив еще одну настройку (не все редакторы/IDE поддерживают оба вида переноса)
• Если использовать жесткий перенос, то что делать с языками где жесткий перенос может сломать код? (например HAML)

Расширение EditorConfig

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

Здесь есть два направления для развития:

Настройки для отдельных редакторов/IDE

Некоторые редакторы/IDE имеют свои особенности, например в jEdit набор кодировок больше, поэтому существует настройка jedit_charset, которая работает только для jedit.

Настройки для отдельных языков/расширений

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

Например npm модуль CodePainter, который использует EditorConfig в качестве конфигурационного файла, позволяет выбрать кавычки (одинарные или двойные), которые будут использована для строк (qoute_type), или расставить пробелы внутри скобок (spaces_in_brackets). Но все это будет работать только для JavaScript.

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

curly_bracket_next_line

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

java_class_path

Может быть использовано другими плагинами

language

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

Где хранятся эти файлы?

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

Для файла, с таким путем: /Users/username/code/project/main.js , плагин будет искать файл .editorconfig следющих местах:

/Users/username/code/project/.editorconfig /Users/username/code/.editorconfig /Users/username/.editorconfig /Users/.editorconfig /.editorconfig 

Поиск можно остановить, задав root=true в одном из конфигов на пути.

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

Как вычисляются настройки внутри файла?

Когда парсер читает файл .editorconfig , он дает больший приоритет настройкам, которые находятся ниже.
Авторы создали небольшое демо [Которое на данный момент, как заметил KindDragon, немного глючит при вычислении путей], где можно поиграться с форматом и посмотреть результат

Форматирование существующего кода

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

editorconfig-tools [ github ]

Набор инструментов для проверки и переформатирования кода. Находится на ранней стадии разработки и не пока не очень стабилен.

ECLint [ github ]

Похож по функциональности на editorconfig-tools, но, в дополнение, умеет анализировать существующий код и генерировать .editorconfig файл. Также на стадии разработки.

CodePainter [ github, npm ]

Использует .editorconfig , но работает только с JavaScript кодом.
Имеет специальные настройки для JS кода.

Плагины, как они работают и как их создавать?

В помощь создателям плагинов создан набор основных компонентов (ядер), которые могут быть использованы в плагинах и берут на себя работу по поиску и парсингуконфигурационных файлов. На данный момент существуют версии на C, Java, Python, ведется работа над JavaScript версией.

Сами плагины стараются перезаписать соответствующие настройки IDE вместо того, чтобы заниматься форматированием самим.

К сожалению, все еще не существует плагинов для такие IDE как Eclipse или NetBeans, их архитектура не позволяет легко менять настройки.

Если среди читающих есть кто-то, готовый взяться за создание плагинов, здесь неплохо расписано, как начать (eng.)

Для пользователей Windows

Чтобы создать файл .editorconfig в Windows Explorer, вам нужно создать файл с именем .editorconfig. и Windows Explorer переименует его в .editorconfig .

Ссылки и как в этом можно поучаствовать

Команда EditorConfig проделала отличную работу, но впереди еще много трудностей, интересных задач и решений:

• Написание и поддержка плагинов для менее известных IDE.
• Разработка ядер для плагинов на других языках и доработка текущих
• Расширение функциональности и добавление новых настроек
• Доработка существующих решений для трансформации кода

• Google Groups.
• Wiki
• Багтрекер
• Так же был создан IRC канал EditorConfig на FreeNode, но он пока полупустой.

• editorconfig
• code formatting
• ide
• intellij idea
• no holywar love and peace
• editor configuration

Начало работы: единообразное написания кода

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

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

Не существует какого-то одного наилучшего стиля оформления кода. Нужно выбрать/сформировать тот стиль, который будет удобен вам и вашей команде.

Главное — код должен быть написан единообразно. Если вы отделяете в разметке большие смысловые блоки (header, footer и т.п.) пустой строкой, делайте это на всех страниц проекта. Если используете два пробела для отступов, не допускайте ситуаций перемешивания, когда на одной строке у вас отступ выполнен двумя пробелами, а несколькими строками ниже — четырьмя пробелами или табуляцией.

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

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

Настройка отступов.

В любом редакторе кода есть раздел c параметрами, которые отвечают за конфигурирование отступов. В моем случае за количество пробелов в отступе отвечает ключ “editor.tabSize”. Можно перейти в раздел параметров редактора, и переконфигурировать необходимые ключи. Но есть еще один вариант — использование EditorConfig. Для любого редактора можно поставить расширение, которое будет автоматически менять настройки редактора по правилам, указанным в файле .editorconfig.

Внутри репозитория личного проекта уже имеется файл .editorconfig. Осталось установить расширение EditorConfig for VS Code.

Для этого нужно нажать комбинацию клавиш: CTRL+SHIFT+X, и в строке поиска расширений указать имя необходимого расширения.

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

Достаточно нажать клавишу табуляции — и отступ по типу двух пробелов будет установлен.

Форматирование разметки и стилей.

Если вы уже проходили курсы в HTML Academy, то успели заметить, что в разметке вложенные элементы используют отступы, чтобы визуально отобразить, на каком уровне иерархии вложенности находиться конкретный элемент относительно родительских элементов:

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

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

Базовая подготовка редактора для работы над личным проектом закончена.

EditorConfig и польза его применения для стандартизации стилей кода

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

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

EditorConfig, по сути, — просто конфигурационный файл. Для реализации поддержки объявленных в нем правил применяются сторонние инструменты или интеграции.

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

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

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

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

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

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

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

Распространенное решение этих проблем — общие настройки редактора как часть проекта. Но это предполагает, что все участники будут использовать одинаковые редакторы, а такое маловероятно.

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

• Visual Studio Code (этим редактором я сам пользуюсь)
• Eclipse
• IntelliJ
• NetBeans

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

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

Чем полезен EditorConfig

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

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

Улучшение читабельности кода — самая важная причина использовать общие настройки стилей. Это помогает поддерживать проект и позволяет работать быстрее.

«На чтение кода мы тратим в 10 раз больше времени, чем на его написание. Мы постоянно читаем старый код — это часть работы по написанию нового. Таким образом, облегчая чтение кода, мы облегчаем и его написание», — Роберт Мартин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[*.xml] indent_size = 4

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

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

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

Если ваш редактор не имеет нативной поддержки, вы скорее всего сможете добавить ее при помощи плагина. Такие редакторы, как Visual Studio Code и Eclipse, поддерживают использование EditorConfig именно таки м образом. Плагины можно найти на сайте EditorConfig — «Download a Plugin».

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

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

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

Не все реализации поддерживают все правила. Это особенно касается специфичных правил типа curly_bracket_next_line. Но объявить эти свойства в любом случае стоит — для пользователей, которые могут их использовать, или чтобы хотя бы задокументировать предпочтительный вариант.

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

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

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

# Declares that this is the top-level configuration root = true # Applies to all files [*] indent_style = space indent_size = 2 # Applies to all Markdown files [*.md] trim_trailing_whitespace = false # Applies to all C# and Java files, overriding rules declared before [*.] indent_size = 4

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

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

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

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

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

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

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

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

root = true [*] indent_style = space indent_size = 2 end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true curly_bracket_next_line = false spaces_around_operators = true [*.bat] end_of_line = crlf [*.cs] curly_bracket_next_line = true [*.] indent_size = 4 [*.] quote_type = single [*.md] trim_trailing_whitespace = false [*.tsv] indent_style = tab

Рекомендации по правилам EditorConfig

Я советую объявить эти правила, если в вашем проекте есть файлы соответствующих форматов. Это поможет избежать больших проблем, связанных с пользовательскими настройками среди разработки.

Пакетные файлы (batch-файлы)

Переводы строк при сохранении должны иметь текстовые представления. Обычно вы этого не видите и об этом не думаете.

Но в разных системах переводы строк обозначаются по-разному (узнать больше).

• В Unix-системах используется lf или \n.
• В Windows — crlf или \r\n.

Batch-файлы, содержащие юниксовские символы перевода строки, ведут себя неожиданным образом. Избежать этого можно, установив end_of_line = crlf . Таким образом обеспечивается применение символов перевода строки Windows. Узнать больше можно здесь.

[*.bat] end_of_line = crlf

Markdown

В Markdown можно сделать разрыв строки в текущем абзаце путем добавления двух пробелов в конце строки. Но редактор может удалить «лишние» пробелы при сохранении. Чтобы этого избежать, можно для .md-файлов установить trim_trailing_whitespace = false .

[*.md] trim_trailing_whitespace = false

TSV

TSV-файлы (TSV — значения, разделенные табуляцией) очень напоминают CSV-файлы (CSV — значения, разделенные запятыми). Но, как следует из самого названия, в качестве разделителя в них используются табы.

Разработчики зачастую автоматически конвертируют табы в пробелы. Но если разделители в TSV-файлах заменятся пробелами, ваша таблица превратится в один столбец. Чтобы этого не случилось, установите для .tsv-файлов indent_style = tab .

[*.tsv] indent_style = tab

Заключение

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

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

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

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