Лучшие практики для форматирования кода на [закрытых] крупных проектах

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

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

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

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

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

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

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

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

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

Eclipse Formatter

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

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

Eclipse Affect Action

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

Перейти к настройкам снова (Java-> Editor-> Сохранить действия) и выберите исходный код формата. Таким образом, код отформатирован при сохранении файла.

Плагин CheckStyle Eclipse

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

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

• Помощь GOTO-> Установите программное обеспечение ...
• Добавить http://eclipse-cs.sf.net/update/
• Установите последний плагин CheckStyle

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

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

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

Предварительно настроенное Eclipse

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

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