Контроль версий и форматирование кодирования - PullRequest
4 голосов
/ 07 апреля 2010

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

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

Если мы допустим «слепые» проверки, код будет выглядеть совершенно по-разному каждый раз, когда кто-то делает проверку. Это усложнит такие вещи, как различия и слияния.

Я говорил с несколькими людьми, и они упомянули следующие решения:

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

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

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

Спасибо,

Martin

Ответы [ 4 ]

9 голосов
/ 07 апреля 2010

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

3 голосов
/ 07 апреля 2010

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

Вариант № 3 в основном заключается в том, чтобы привить людям привычки - на самом деле форматирование кода не доставляет особых хлопот, если каждый может привыкнуть к одной и той же привычке. Единственный код, который вам нужно отформатировать, это тот, который вы создаете / трогаете; остальное будет отформатировано в кассе.

1 голос
/ 07 апреля 2010

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

Однако лучше использовать вариант № 3, так как при разработке легче установить правила форматирования в IDE.

0 голосов
/ 07 апреля 2010

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

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

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

...