Обеспечить соблюдение стандартов кодирования во всех файлах проекта при сборке

Question

Я знаю, что в Stackoverflow есть несколько похожих вопросов, но они были связаны с .Net или не имели никакого ответа, который помог бы нам.

Дело в следующем: с некоторыми друзьями мы начинаемпроект с открытым исходным кодом.При определении основ успешного проекта, который, мы надеемся, возник вопрос: как обеспечить соблюдение кодовых соглашений проекта?

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

В проекте используется Struts 2 + Spring + Hibernate, используется Maven 2 (подумывает о переходе на Maven 3).Мы знаем, что можем использовать «CheckStyle» для тестирования файлов Java, но это оставляет некоторые открытые вопросы, на которые, надеюсь, кто-то может ответить:

• Существует какой-то инструмент для проверки стиля файлов XML и SQL, ломающийсясборка, если они не соответствуют правилам?
• Есть какой-то инструмент, который автоматически переформатирует исходные файлы (Java, XML, SQL) в соответствии с требуемым соглашением?Можно ли как-нибудь интегрировать с Maven?

Мы могли бы найти файлы Jalopy для Java, но мы бы предпочли бесплатный инструмент (насколько нам известно, последняя версия платная).И мы все еще не могли найти что-нибудь для SQL / XML.

ОБНОВЛЕНИЕ: просто чтобы прояснить: я не спрашиваю о PMD, Checkstyle или этих инструментах.Я прошу инструменты, которые:

• Автоматически форматируют файлы SQL, XML и / или Java в соответствии с требуемым соглашением о кодировании (4 пробела и т. Д.)
• Обнаружение файлов SQL и XML с помощьюнеправильный формат и нарушить сборку из-за этого.

Answer 1

Стандартные инструменты, которые я бы использовал для Java:

• CheckStyle
• FindBugs
• PMD

Все они способны проваливать сборку Maven при достижении определенного порога.

Но вопрос, конечно, в том: кто и когда запускает эти инструменты?

Я бы предложил установить сервер непрерывной интеграции, например hudson , и настроить его для запуска контрольного стиля maven, целей findbugs и pmd (у hudson есть плагины для отображения графиков для всех этих инструментов), и вы получите всегда смотрите, кто провалил сборку, потому что вы можете видеть, кто совершил что-то между двумя сборками.

Answer 2

Каждый из PMD, Checkstyle, Findbugs и т. Д. Имеет Eclipse и другие плагины IDE.Вы также можете настроить выбранную среду IDE для форматирования в соответствии со стилем, который вы хотите, а затем поделиться этой конфигурацией (в виде файла) с членами команды.

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

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

Answer 3

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

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

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

Answer 4

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