2009-12-23 6 views
14

Я поддерживаю сборку для большого проекта с 20 разработчиками по всему миру.Рекомендации по форматированию кода по крупным проектам

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

Основная проблема с этим решением заключается в том, что если разработчик не запускает полную сборку Maven перед проверкой (скажем, они запускают модульные тесты от Eclipse), их код не будет отформатирован. Затем следующий разработчик, который редактирует файл, может иметь много и много различий в несвязанных разделах кода после запуска форматирования.

Какая стратегия форматирования исходного кода лучше всего подходит для вас в крупных проектах? Другой вариант, который я рассматривал, - это форматирование в ночное время с использованием автоматизированного процесса.

ответ

16

В сборке Maven должны быть только сообщения об ошибках форматирования, используя что-то вроде Checkstyle, а не автоматически форматируя код. Это то, что, по-видимому, подразумевало ваше описание. Таким образом, ошибки сообщаются разработчику/Хадсону во время сборки, и их можно решить по мере необходимости.

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

1

Можете ли вы установить правило проверки в Perforce для форматирования кода при регистрации? Я не использовал perforce, поэтому я не могу комментировать, но это то, о чем мы думали, было бы уместно, когда мы обсуждали варианты форматирования форматирования кода в нашей команде.

2

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

+1

Я видел, как это терпело неудачу несколько раз. Мне гораздо легче отслеживать/применять правила, если он интегрирован в процесс автоматической сборки, используя Maven/Checkstyle/Hudson. –

+1

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

+0

В этом случае я бы предложил использовать плагин Checkstyle Eclipse и настроить его на использование тех же правил, что и Hudson. –

0

Это может не сильно помочь, но Go language source tree автоматически форматирует то, что вы нажимаете на него, используя приложение командной строки, которое они установили. Это сделано в Mercurial, а не в Perforce. Но, может быть, вы можете видеть, как они это сделали. Подробности должны быть где-то в golang.org.

6

Один из способов справиться с этим будет форматировать код в предварительно зафиксированной крючок с чем-то вроде Jalopy или JIndent или даже Eclipse, встроенные в код форматировщик (который вы можете invoke from the command line). AFAIK, это единственный способ убедиться, что код версии всегда правильно сформирован, если вы не можете заставить людей запускать автоматическую сборку перед совершением. Но я не знаю, поддерживает ли Perforce предварительные фиксации.

Если это не так, другой вариант заключается в использовании Jalopy Maven Plugin или Maven Checkstyle Plugin во время сборки и сбоя сборки при нарушении правила (и сообщите об этом механизму CI). Однако неудачи сборки косметических вещей могут быть довольно раздражающими.

Так что, действительно, запуск ночного процесса для форматирования кода может быть альтернативой. В этом случае Jalopy Maven Plugin или другие упомянутые инструменты могут вам помочь, на самом деле это будет зависеть, если вы хотите использовать Maven или нет для этой работы.

0

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

Лично мы просто используем Eclipse Save Actions и сообщаем об этом при форматировании при сохранении. Достаточно хорошо для нас.

14

Чтобы обеспечить последовательное форматирование ваших проектов, вам необходимо настроить инструменты, чтобы сделать это автоматически. Я хотел бы предложить следующее:

Затмение Formatter

Для Eclipse, есть опция в настройках (Java-> Код Стиль-> Formatter), где вы можете настроить, как вы хотите, чтобы ваши проекты должны быть отформатированы. Создайте новый профиль и разместите там свою конфигурацию.

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

Затмения Сохранить действия

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

Вернитесь к настройкам еще раз (Java-> Редактор-> Сохранить действия) и выберите Формат исходного кода. Таким образом, код форматируется при сохранении файла.

Затмение Checkstyle Плагин

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

Установите плагин Checkstyle для Eclipse:

  • Goto Помощь-> Установка программного обеспечения ...
  • Добавить http://eclipse-cs.sf.net/update/
  • Установите последнюю версию Checkstyle Plugin

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

Преимущество наличия удаленной конфигурации заключается в том, что вы также можете ссылаться на нее с помощью maven-checkstyle-plugin, и он может предоставить вам отчеты, запустив их на сервере CI.

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

Предварительно настроенные Затмения

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

Бонус с побочным эффектом: вы не согласны с версией на платформе разработки. Управление конфигурацией относится не только к исходному коду, но и к инструментам разработки. Сохраняет вещи более предсказуемыми.

+1

Eclipse - ужасный способ переформатировать код. Наш опыт заключается в том, что он не постоянно переформатирует все файлы, поэтому он создает различия между ветвями с течением времени. Jalopy, Jacobe, JIndent, или что-то в этом роде предпочтительнее. – cdunn2001

2

Лучшим решением, которое я видел для этого, является подход, принятый CXF, подробно описанный в Connecting Maven, Eclipse, Checkstyle, and PMD.

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

Это подразумевает большую конфигурацию для Eclipse. Они автоматизируют этот шаг, объединяя коллекцию плагинов Maven, которая создаст рабочее пространство CXF, которое включает в себя необходимую конфигурацию checkstyle/autoformatting.

Смежные вопросы