Было бы плохой идеей периодически запускать средства форматирования кода в хранилище?

Я подумываю о создании задания cron, которое проверяет код, запускает на нем средства форматирования кода и, если что-то изменяется, фиксирует изменения и возвращает их обратно.

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

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

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

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

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

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

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

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

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

С мерзавцем , предварительно совершить крюк , делая это было бы полезно. Во многих проектах на C или C ++, созданных с использованием некоторого Makefile , я добавляю несколько indentцелей (которые запускаются соответствующим образом как средства форматирования кода, такие как indentor astyle) и ожидаю, что участники будут работать make indentрегулярно. Кстати, вы даже можете добавить некоторые makeправила, чтобы убедиться, что git hooks были установлены (или для их установки).

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

Контроль версий - это, в основном, некоторый инструмент, помогающий общаться между разработчиками (включая самого себя через несколько месяцев). Ваше программное обеспечение не нуждается в VC или форматировании, но ваша команда делает это.

Кстати, разные сообщества и разные языки программирования имеют разные взгляды на форматирование кода. Например, Go имеет только один стиль форматирования кода, но в C или C ++ их много.

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

Лучшим подходом было бы включить проверку формата в ваш инструмент сборки. (В Java есть Checkstyle ). Затем разрешайте людям объединять свои ветви с основной веткой только в том случае, если сборка прошла (включая форматирование).

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

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

В том же духе, что и рекомендация @ BasileStarynkevitch, мы используем перехватчики сообщений git на стороне сервера для отправки «рекомендательных писем» о стиле кода.

Если я отправляю коммит, содержащий нарушения стиля, сервер git origin отправит мне электронное письмо, которое сообщит мне, что я нарушил правила стиля и рекомендует исправить код. Это, однако, не предписывает это, потому что могут быть веские причины для нарушения стиля дома (например, длинные строки, превышающие ограничение длины строки).

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

Чтобы добавить аспект «социальной проблемы», стоит побудить людей исправлять косметические и стилистические дефекты по мере их обнаружения. У нас есть стандартное сообщение коммита "Косметика". исправления стиля кода, известные другим разработчикам, не содержат критических изменений.

Как говорит @DocBrown, другой вариант - применить стиль кода в вашей IDE. Мы используем CodeMaid с Visual Studio, чтобы исправить многие распространенные ошибки стиля. Он будет работать при сохранении файлов кода, а это означает, что код с плохим стилем никогда не должен превращаться в репозиторий ... в теории :-).

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

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

Я не хочу проверять это прямо сейчас на работе, но вы должны попробовать это сами.

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

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

Вместо этого вы можете поместить его в ночной или еженедельный.

Но даже ночью может быть плохой идеей.

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

В противном случае запускайте его 1-2 раза в год в праздничный сезон, когда конфликты слияний не возникнут.

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

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

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

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

Это ужасная идея.

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

Если вы хотите делать это на регулярной основе, это просто ужасно.

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

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

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

Это компромисс между более чистым форматом кода и более точным и легким для понимания Git-историей. Зависит от характера вашего проекта и от того, как часто вы погружаетесь в историю git или обвиняете, чтобы понять, что происходит. Если вы работаете над чем-то новым и не должны поддерживать обратную совместимость, история обычно не играет такой важной роли.

Эта идея похожа на некоторые другие ответы, но я не могу комментировать свои предложения.

Один из вариантов - установить псевдоним (или перехватить, или что-то еще) для функции фиксации, которая запускает средство форматирования кода для кода, подлежащего фиксации, до его фиксации.

Это может иметь 2 (или более) результата:

1) Покажите пользователю предложенные изменения и попросите их одобрения, чтобы применить и зафиксировать изменения.

2) Проигнорируйте предложенные изменения и передайте исходный код.

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

Это может быть хорошим балансом автоматической проверки всего кода, который вы хотите, при этом предоставляя разработчикам гибкость в соответствии с их потребностями. Это также позволяет не «автоматически отклонять» код с различиями форматирования, как упоминалось в других ответах. С «Я рассмотрел и одобрил автоматические исправления форматирования; опция commit ', она по-прежнему сохраняет личную ответственность за работу каждого разработчика и не связывается с VCS.

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

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

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

Проверки кода предотвратят любые ошибочные.

Еще одно место, где я бы это сделал - это сделать его частью сборки. В моем случае это так, что сборки maven переформатируют XML, очищают pom-файлы и переформатируют код.

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