Форматирование кода перед фиксацией в GIT

#git #bitbucket #code-formatting

#git #bitbucket #форматирование кода

Вопрос:

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

Должен ли я попросить всех разработчиков форматировать код в одном стиле?

Могу ли я попросить GIT каким-то образом отформатировать код в соответствии с тем же стилем? Возможно ли добиться автоматического форматирования кода с помощью BitBucket?

Комментарии:

1. «Должен ли я попросить всех разработчиков форматировать код в одном стиле?» Безусловно, да. Выберите руководство по стилю и придерживайтесь его для проекта. Если вы выполняете проверку кода, включите стиль кода как часть проверки. Если есть инструмент, который автоматически проверяет код на соответствие какому-либо стандарту для вашего языка, используйте его.

Ответ №1:

Должен ли я попросить всех разработчиков форматировать код в одном стиле?

Да, это хорошая идея.

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

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

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

Могу ли я попросить GIT каким-то образом отформатировать код в соответствии с тем же стилем? Возможно ли добиться автоматического форматирования кода с помощью BitBucket?

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

Для этого и нужны обзоры кода, и в коде всегда есть исключения, когда человек сделает это лучше (например, в C land, clang-format в основном отлично справляется, но отстой практически во всем, что связано с нетривиальными списками инициализаторов). Принуждение всех к принятию машинной интерпретации, скорее всего, просто помешает.

Комментарии:

1. Нет, это паршивая идея. Идеальное решение еще не разработано (возможности для бизнеса, ребята), но идеальным решением было бы двунаправленное форматирование — когда вы что-то проверяете, оно форматирует в соответствии с вашими желаемыми настройками, а когда вы возвращаете его обратно, оно устанавливает его в соответствии со стандартом компании. Очевидное решение и никакого кодонацизма.

Ответ №2:

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

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

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

Ответ №3:

Должен ли я попросить всех разработчиков форматировать код в одном стиле?

Да, и может быть несколько инструментов, которые могут помочь вам именно в этом.

Редакторы и среды Som поддерживают формат файла с именем .editorconfig, в котором вы можете указать стиль кодирования. например, табуляция или пробелы, а если пробелы, то сколько пробелов для одного отступа кода. https://editorconfig.org /

Я использую это с Visual Studio, где это работает очень хорошо. Другие среды или редакторы могут потребовать от вас добавления плагина перед его поддержкой (например, визуальный код) или иметь свой собственный способ определения стиля кода в проекте.

Могу ли я попросить GIT каким-то образом отформатировать код в соответствии с тем же стилем? Возможно ли добиться автоматического форматирования кода с помощью BitBucket?

Если вы хотите применить стиль кода, а не просто согласовать его (.editorconfig), то вам может потребоваться изучить git-хукеры.

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

https://githooks.com/

Ответ №4:

Насколько мне известно, в BitBucket этого нет.

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

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

В случае моей команды мы используем MS Visual Studio и стиль Allmann, поскольку он изначально поддерживается автоформатированием.

Ответ №5:

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

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

.vscode/settings.json

 {
    "editor.formatOnSave": true
}
  

Чтобы убедиться, что у всех есть средство форматирования, вы могли бы вместо этого использовать devcontainers, расширения могут быть перечислены для установки здесь и будут установлены, когда кто-либо из команды откроет devcontainer.

.devcontainer.json или .devcontainer/devcontainer.json

 {
  // …
  "customizations": {
    "vscode": {
      "settings": {
        "editor.formatOnSave": true
      },
      "extensions": [
        "esbenp.prettier-vscode"
      ]
    }
  }
}
  

Для последнего требуется, чтобы было установлено расширение devcontainer и Docker был доступен.


Обратите внимание, что эти настройки переопределяют пользовательские настройки из VS Code, при работе в workspace или devcontainer эти настройки применяются до пользовательских пользовательских настроек.