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

Управление пробелами в исходном коде не одна из этих проблем.

Сначала краткое изложение моей предыдущей публикации Почему Линтинг заставляет меня зевать. Команды должны согласовать руководство по стилю. Он никогда не будет соблюдаться без какого-либо принуждения. Некоторые правила требуют применения суждения, для этого у нас есть линтер. Но для чисто механических правил, например, где ставить пробелы, нет необходимости в UX, в котором проблемы представляются разработчику. Их нужно просто применять, всегда и без усилий. В проекте Angular и для внутреннего исходного кода Google мы просто требуем, чтобы код был отформатирован с помощью определенного средства форматирования с некоторой конфигурацией. Больше нечего решать или делать.

Недавно я видел несколько сообщений о Prettier, которая только что достигла 1.0. См. Http://jlongster.com/prettier-1.0. Prettier, кажется, понимает это правильно: несколько вариантов конфигурации и полностью самоуверенный: любые два файла с одинаковым AST будут отформатированы одинаково. Недостатком, по крайней мере сейчас, является отсутствие поддержки TypeScript. Но формат clang, изначально предназначенный для C ++, очень хорошо обрабатывает TypeScript, благодаря большой работе от @martin_probst. Рекомендую попробовать!

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

Есть несколько способов справиться с этим:
- Оставьте код в покое, но убедитесь, что файл форматируется всякий раз, когда он изменяется.
- Как и в предыдущем случае, но только в принудительном порядке измененные диапазоны в файл отформатирован.
- Отформатируйте все в большом формате.

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

Начиная

Выберите конфигурацию. Как и Prettier, clang-format имеет несколько параметров. Они помещаются в файл с именем .clang-format в корне вашего проекта, чтобы редакторы и инструменты могли использовать одну и ту же конфигурацию. Вы можете прочитать о параметрах в документации в формате clang или попробовать этот онлайн-редактор конфигурации: https://clangformat.com/

Для Angular это выглядит так:

Установите clang-format в свой проект или, если вы используете инструмент сборки gulp, установите gulp-clang-format. Обязательно закрепите версию clang-format. Вы не хотите получать новую версию, если не готовы снова переформатировать файлы.

Я задокументирую настройку gulp ниже, но вы можете сделать что-то подобное в другом инструменте сборки. Здесь используется синтаксис Es2015 в gulpfile.js:

Теперь внесите большие изменения в форматирование с помощью gulp format.

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

В идеале ошибка формата должна быть отдельным статусом в запросе на вытягивание из ошибок тестирования. Вам действительно нужны оба бита информации: раннее указание на то, что форматтер не запустился, когда он должен был (возможно, вы можете исправить его и повторно нажать перед приготовлением кофе), а также результаты теста (отстойно возвращаться из приготовление кофе, и единственным результатом CI было то, что вы не отформатировали файл). Я хотел бы найти сервис, который сделает это для GitHub!

Сохранение кода в формате

Поначалу ваших коллег будет раздражать красная сборка, когда они что-то меняют. Вам нужно будет убедить их, что форматтеру стоит потратить 2 минуты на локальную настройку. Лучшая настройка - та, которая требует наименьшего количества размышлений: настройте ваш редактор на форматирование файлов при сохранении. Для Visual Studio Code я использую это расширение. Подобный плагин доступен во всех известных мне редакторах.

Другой вариант - установить команду git clang-format. Это приятно, потому что он работает быстро, даже если у вас большая кодовая база, просто касаясь файлов, которые вы изменили. Или вы можете просто запустить ту же команду gulp format, которую мы использовали выше, для массового форматирования всего, если она не слишком медленная.

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

Наконец, не забудьте удалить все правила линтера, которые служат только для напоминания о пробелах. Это больше не работа линтера!