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
    [{package.json,.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 // Нет совпадения


    {s1,s2,s3} - Любая из строк разделенных запятыми

    Пример: [index.{js,html}]
    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
    [*.{js,css}]
    indent_style = space
    indent_size = 2
    # Но не переформатируем минифицированные JS и CSS файлы.
    [*.min.*]
    indent_style = ignore
    trim_trailing_whitespace = false
    insert_final_newline = ignore
    


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


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

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

    На данный момент свойство max_line_length существует, но работает только в vim.


    Расширение 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

    Полный список можно посмотреть тут (eng.)

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


    Когда плагину нужно будет вычислить конфигурацию для файла, он будет подниматься по файловому дереву, от директории с файлом до корня, и загружать настройки из каждого .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.
    • Разработка ядер для плагинов на других языках и доработка текущих
    • Расширение функциональности и добавление новых настроек
    • Доработка существующих решений для трансформации кода

    Если кому-то из читателей интересно было бы принять участие в работе проекта, вот хорошие способы связаться с разработчиками (все на английском):


    Я не в команде проекта, но использую .editorconfig сам и с удовольствием передам ваши предложения и пожелания — пишите в личную почту.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 32

      +8
      Вы разработчик? Хорошо бы иметь возможность экспортировать мои текущие настройки в .editorconfig.
        0
        Я не разработчик, идея хорошая.
        На данный момент можно отформатировать несколько файлов существующего кода с существующими настройками, а потом использовать eclint для генерации конфига.

        Насколько я понимаю, вы предлагаете научить плагины экспортировать настройки из IDE? Думаю, что это заслуживает отдельного issue в багтрекере.
        +1
        Спасибо за статью! Как раз хотел про него написать после того как они наконец обновили extension для Visual Studio, исправили в нем проблемы с VS2013.
          +2
          Там проблема была в кривой сборке. Я когда решил разобраться, что же там такое, его сам скомпилил из исходников и обнаружил, что всё работает. Другое дело, что зависящая от него TabSanity почему-то ломает автокомплит в Nemerle.
          +3
          * — Любое количество символов кроме разделителя пути (/)
          Пример: [*.js]
          lib/source.js // Нет совпадения

          Live демо показывает что это не так
            +2
            Зато
            [lib/*.js]
            lib/source.js // Совпадения
            lib/another_lib/source.js // Нет совпадения

            [lib/**.js]
            lib/source.js // Совпадения
            lib/another_lib/source.js // Совпадения
              0
              Это похоже на поведение описанное в статье.
              0
              Вы правы, похоже демо неправильно понимает символ *, сделаю issue.
              +1
              Хороший проект но плагины немного глючные.
                0
                Все в наших руках!
                +3
                Отличная штука. Можно ещё и в облаке хранить настройки.

                Оффтоп. Эх, ещё бы возможность экспортировать цветовую схему кода из JetBrains IDE в Sublime…
                  +5
                  Ммм… какой у вас шрифт в подзаголовках крутой (Menlo) =)

                  А под Eclipse будет подобный плагин? Что-то в посте не нашел его упоминания.
                  +2
                  Изначальная задача EditorConfig — создать минимальный набор свойств, который работал бы во всех основных IDE.

                  Думаю идти надо было от обратного. Реализовать все известные на сегодняшний день настройки, а будут ли они поддерживаться IDE, проблема самой IDE. Зачем ограничивать формат?
                    +3
                    Смысл же как раз в использование настроек во всех IDE которыми вы пользуетесь. Не будет от него пользы, если настройка есть в файл но нигде не поддерживается.
                      +5
                      Если именно нигде не поддерживается, то смысла не будет, но если не поддерживается в тех IDE, которые в принципе не умеют, на пример, разукрашивать синтаксис, то это нормально.
                      Представим ситуацию, работаю я на Eclipse и хорошенько ее под себя настроил. Теперь хочу перейти на vim, перенеся все настройки туда. Какой прок от EC, если он эти настройки не поддерживает, хотя оба IDE их смогут прекрасно воспроизвести? Зачем я должен беспокоится о том, что какой нить там nodepad++ мои настройки не поймет? Когда он научится с ними работать, вам не нужно будет добавлять их в EC, а достаточно будет просто заставить nodepad++ читать уже существующую конфигурацию.

                      Если честно, я просто не понимаю смысла вашей цели — использовать настройки во всех IDE — а может вы сами не понимаете своей цели )
                        +3
                        Я говорю не про все IDE в мире, а все редакторы которые используют программисты в проекте. Например: Visual Studio, Notepad++, Sublime Text, под Linux скажем Vim или Geany. Моя цель чтобы программисты под всем этими редакторами использовали одинаковые отступы в коде, одинакового размера.
                          +1
                          А какую цель вы преследовали, ограничивая формат? Что плохого в том, что переходя на другую IDE мой конфигурационный файл не будет работать в полной мере с учетом того, что проблема здесь не в файле, а в возможностях самой IDE?
                            +1
                            Во первых, я не разработчик EditorConfig. Только немного контрибьютил в VS etension. Я не ограничивал формат :)

                            Цель преследовалось чтобы пользователь мог ожидать во всех редакторах с EditorConfig все основные свойства будут работать. Я лично не вижу смысла в десятках свойств из которых только несколько будет работать в нужных тебе редакторах. Это только усложнит реализацию и поддержку плагинов.
                              +2
                              Я так не думаю. Если редактор не поддерживает то или иное свойство, плагин его просто не обработает, это нисколько не усложняет логику, а если редактор может обработать свойство, то мы намеренно не позволяем ему это сделать, что не есть хорошо.
                                +1
                                Никто никому не запрещает расширять формат. Просто это большая работа.
                                `trim_trailing_whitespace` вроде не так давно добавился.
                                  +3
                                  Вы не поняли цель, которую преследовали разработчики EditorConfig. Их задачей было не позволить вам переносить настройки и цветовые схемы между лично вашими IDE (ваши вкусы — только ваше дело). Их задачей было сделать формат, который позволял бы убедиться, что ВСЕ разработчики в рамках ОДНОГО проекта одинаково форматируют код, всё. Каждый пусть сам настраивает свою IDE под себя, но проблема «Табы vs пробелы» должна быть решена на корню, здесь, в этом файле в корне репозитория.
                                    +2
                                    Если речь только о «Табы vs пробелы», то да, я не понял цели и все вполне оправдано, один формат, одно свойство, больше ничего не нужно. Если речь идет не только о табах и пробелах, то на мой вопрос выше ответа я не получил. Повторю — как быть если ВСЕ разработчики в рамках ОДНОГО проекта используют разные IDE, часть форматов которых не поддерживается в EC?
                                      +1
                                      Ну на самом деле кроме табов/пробелов (у нас пробелы), кодировки (у нас только UTF-8), завершающих строку пробелов (у нас их быть не должно) и завершающего перевода строки в конце файла (у нас он быть должен) других трений с коллегами нет (больше всего доставляет новая строка в конце файла, а Sublime он почему-то по дефорлту выключен, а ты потом делай git add -p и отделяй свои изменения от изменённых последних строк). Всё остальное уж совсем язык-специфично и просто кому как нравится. Т.е. лично меня уже устраивает функциональность EC.

                                      В принципе народ там хочет впилить крутилки для конкретных языков, посмотрим, что у них получится.

                                      Какие именно нужные вам форматы не поддерживаются в ЕС сейчас?
                                        +1
                                        Все же сомневаюсь, что дело именно в этих трех мелочах. Ради этого создавать новый формат? Не думаю. От того и возник вопрос — почему пошли путем ограничения? Ответа пока не увидел. Последим за проектом, может нароем собаку.
                                          +2
                                          Ну, я думаю, что это головная боль для многих популярных open-source проектов — как заставить всех отправляющих патчи людей хоть более-менее одинаково форматировать код?

                                          Пишешь в CONTRIBUTING.md — не помогает, пишешь в README.md КАПСОМ — не помогает, приходится изобретать велосипеды.
                        +1
                        Думаю разработчики решили следовать принципу KISS и начать с минимальными настройками. Таким образом не один разработчик получает один конфиг для разных IDE, а все разработчики получают общие минимальные настройки.
                        Именно легкость понимания и минимальное количество действий необходимое для того, чтобы начать использовать EditorConfig позволяет разработчикам быстро начать использовать его на проектах.

                        Ваш подход решает другую задачу — позволить разработчику менять IDE, сохраняя настройки. Это интересная задача, решение которой может помочь другим разработчикам, и, возможно, ее можно решить расширив формат EditorConfig, если найдется кто-то, кому это будет интересно сделать.
                          0
                          В этом то и загвоздка. Вот вы считаете, что если EC будет поддерживать больше конфигов (каких не поддерживает несколько IDE), то некоторые разработчики (использующие эти самые IDE) вылетят из пользователей EC. Это не верно. Все разработчики так же получат полный функционал EC, просто некоторые из них, кто пользуется более современными (назовем их так) IDE, получать больший функционал, а другие меньший.
                        +1
                        в конце строк должно быть либо CRLF либо LF.

                        Отдельные программы для мака всё ещё используют CR для конца строки.
                          0
                          Это было осознанное решение команды EditorConfig, оно распространяется только на сам файл .editorconfig
                          Внутри вашего проекта вы можете использовать:
                          end_of_line = CR
                          
                          +2
                          Эх. А хоткеи я так понял и не планируются? Было бы так хорошо подобную штуку для них…
                            0
                            Думаю, что название проекта (и заголовок, который я придумал) немного всех запутали.
                            Задача EditorConfig — общий конфиг между разработчиками одного проекта. Не думаю, что кто-то захочет менять горячие клавиши для каждого проекта.

                            Хотя идея классная, я бы покопал на эту тему. EditorShortcutConfig?

                          Only users with full accounts can post comments. Log in, please.