Я поддерживаю сборку для большого Java EE/Maven/Hudson/Perforce проект с участием около 20 разработчиков по всему миру.
Решением для форматирования кода является форматирование кода с помощью Jalopy, когда разработчик запускает сборку, тем самым обеспечивая любой код, который имеет не форматированный, форматируется до регистрации.
Основная проблема с этим решением заключается в том, что если разработчик не запускает полную сборку Maven перед проверкой (скажем, они запускают модульные тесты из Eclipse), их код не будет отформатирован. Затем следующий разработчик, который редактирует файл, может иметь много и много различий в несвязанных разделах кода после запуска форматирования.
Какая стратегия форматирования исходных текстов лучше всего подходит для вас в крупных проектах? Другой вариант, который я рассматривал, - это форматирование в ночное время с использованием автоматизированного процесса.
Конструкция Maven должна просто сообщать о ошибках форматирования, используя что-то вроде Checkstyle, а не автоматически форматировать код. Это то, что, по-видимому, подразумевало ваше описание. Таким образом, ошибки сообщаются разработчику/Хадсону во время сборки и могут быть разрешены по мере необходимости.
Я бы также предложил использовать инструмент, например Sonar, чтобы сохранить историю ошибок форматирования с течением времени (см. их функциональность машинного времени).
Чтобы обеспечить последовательное форматирование ваших проектов, вам нужно настроить инструменты для этого автоматически. Я бы предложил следующее:
Форматирование Eclipse
Для Eclipse есть опция в настройках (Java- > Code Style- > Formatter), где вы можете настроить способ форматирования ваших проектов. Создайте новый профиль и разместите там свою конфигурацию.
Как только вы закончите, есть функция экспорта (она хорошо скрыта, нажмите "Изменить", а затем "Экспорт" ). Передайте конфигурацию остальной части команды, чтобы ее можно было импортировать.
Eclipse Сохранить действия
Все еще имея конфигуратор форматирования, не гарантирует, что разработчики будут форматировать код перед фиксацией, поэтому вам нужно настроить автоматический формат.
Перейдите к настройкам еще раз (Java- > Editor- > Save Actions) и выберите "Формат исходного кода". Таким образом, код форматируется при сохранении файла.
Плагин Eclipse Checkstyle
Некоторые разработчики могут забыть сделать эти шаги правильно, поэтому вам нужен способ найти это.
Установите плагин Checkstyle для Eclipse:
После установки плагина вы можете создать для него конфигурацию. Конфигурация затем может быть экспортирована для остальной части команды или даже лучше загружена на сервер и будет дистанционно удаляться по конфигурации.
Преимущество наличия удаленной конфигурации заключается в том, что вы также можете ссылаться на нее с помощью модуля maven-checkstyle-plugin, и он может предоставить вам отчеты, запустив их на сервере CI.
Если вы хотите быть жестким ядром, вы можете установить базовую конфигурацию (те, которые выполняются автоматически с помощью форматирования) на ошибки вместо предупреждений, чтобы разработчик с неправильно сконфигурированным затмением увидел ошибку до совершения.
Предварительно настроенное Eclipse
Если вы хотите перейти на следующий уровень, вы создадите предварительно настроенное затмение и распространяете эту версию своим разработчикам, чтобы им ничего не нужно было делать.
Бонус побочного эффекта: вы не учитываете несоответствия версии на платформе разработки. Управление конфигурацией относится не только к исходному коду, но и к инструментам разработки. Сохраняет вещи более предсказуемыми.
Один из способов справиться с этим - это форматировать код в привязке до фиксации с помощью Jalopy или JIndent или даже встроенный форматировщик кода Eclipse (который вы можете вызывать из командной строки). AFAIK, это единственный способ обеспечить правильное формирование кода версии всегда, если вы не можете заставить людей запускать автоматическую сборку перед совершением. Но я не знаю, поддерживает ли Perforce предварительные фиксации.
Если это не так, другим вариантом будет использование Jalopy Maven Plugin или Maven Checkstyle Plugin во время сборки и сбой сборки при нарушении правила (и сообщите об этом механизму CI). Построить неудачи для косметических вещей может быть довольно раздражающим, хотя.
Итак, действительно, запуск ночного процесса для форматирования кода может быть альтернативой. В этом случае Jalopy Maven Plugin или другие упомянутые инструменты могут вам помочь, на самом деле это будет зависеть, если вы хотите использовать Maven или нет для этого работа.
Если все (или большинство) ваших разработчиков используют Eclipse, вы можете экспортировать правила форматирования и сохранять действия в своей команде, и каждый из них имеет одинаковые предпочтения.
Лучшее решение, которое я видел для этого, - это подход, сделанный CXF, подробно описанный в Подключение Maven, Eclipse, Checkstyle и PMD.
Они объединяют checkstyle с Eclipse, используя плагин Eclipse-cs Dimitris, упомянутый в другом ответе. Это позволяет Eclipse генерировать ошибки, если их код нарушает правила форматирования кода. Они также интегрируют checkstyle с Maven, так что шаг проверки завершится неудачно, если их код не будет соответствовать правилам checkstyle. Они также имеют избыточный набор правил автоматического форматирования, определенных в Eclipse, что позволяет легко форматировать код, который будет проходить стандарты проверки.
Это подразумевает большую конфигурацию для Eclipse. Они автоматизируют этот шаг, объединяя коллекцию плагинов Maven, которая создаст рабочее пространство CXF, которое включает в себя необходимую конфигурацию checkstyle/autoformatting.
Можете ли вы установить правило проверки в Perforce для форматирования кода при проверке? Я не использовал perforce, поэтому я не могу комментировать, но это то, о чем мы думали, было бы уместно, когда мы обсуждали варианты форматирования форматирования кода в нашей команде.
Это может не сильно помочь, но Go language source tree автоматически форматирует то, что вы нажимаете на него, используя приложение командной строки, которое они я настроен. Это сделано в Mercurial, а не в Perforce. Но, может быть, вы можете видеть, как они это сделали. Подробности должны находиться где-то в golang.org.
Если для вас важно правильное форматирование, настройте Perforce для выполнения собственного прогона форматирования в checkin и сообщите ему об отказе от коммита, если форматированная версия исходного файла отличается от отформатированной.
Лично мы просто используем Eclipse Save Actions и говорим об этом для форматирования при сохранении. Достаточно хорошо для нас.