Форматирование кода и различия в управлении исходным кодом

Question

Какие продукты контроля версий имеют функцию «diff», которая игнорирует пробелы, фигурные скобки и т. Д. При расчете разницы между зарегистрированными версиями? Кажется, я помню, что diff Clearcase сделал это, но Visual SourceSafe (или, по крайней мере, версию, которую я использовал) не сделал.

Причина, по которой я спрашиваю, вероятно, довольно типична. У четырех совершенно разумных разработчиков в команде есть четыре совершенно разных способа форматирования их кода. После проверки кода, который последний раз был изменен кем-то другим, каждый немедленно запустит какую-то программу или макрос редактора, чтобы отформатировать вещи так, как им нравится. Они делают реальные изменения кода. Они регистрируют свои изменения. Они уходят в отпуск. Два дня спустя эта программа, которая работала нормально два года, взрывается. Разработчик, назначенный на ошибку, проводит различие между версиями и находит 204 различия, только 3 из которых имеют какое-либо значение, потому что алгоритм сравнения хромает.

Да, у вас могут быть стандарты кодирования. Большинство всех находит их ужасными. Решение, где каждый может съесть свой торт и съесть его, кажется гораздо более предпочтительным.

=========

РЕДАКТИРОВАТЬ: Спасибо всем за отличные предложения.

Что я забираю из этого:

(1) Предпочтительна система управления исходным кодом с подключаемыми типами diff.

(2) Найдите diff с подходящими параметрами.

(3) Используйте хорошую программу форматирования исходного кода и установите стандарт регистрации.

Звучит как план. Еще раз спасибо.

Answer 1

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

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

И если кто-то просто не согласен работать с выбранным стилем, просто напомните ему (или ей), что он программирует как профессия, а не хобби, см. http://www.ericsink.com/entries/No_Great_Hackers.html

Answer 2

Git имеет следующие опции:

• --ignore-space-at-eol

  Игнорировать изменения пробелов в EOL.

• -b, --ignore-space-change

  Игнорировать изменения количества пробелов. Это игнорирует пробелы в конце строки и учитывает все другие последовательности одного или нескольких пробельные символы должны быть эквивалентны.

• -w, --ignore-all-space

  Игнорировать пробелы при сравнении строк. Это игнорирует различия, даже если одна строка имеет пробел, где другая строка имеет нет.

Я не уверен, что изменения скобок можно игнорировать с помощью diff в Git.

Если это код C / C ++, вы можете определить правила Astyle и затем преобразовать стиль скобок исходного кода в тот, который вам нужен, используя Astyle . A git diff будет выдавать нормальный вывод.

Answer 3

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

Пара дополнительных шагов, но они уже используют инструменты отступа при работе. Может быть, это может быть запущенный скрипт регистрации?

Изменить: возможно, это также решило бы проблему скобки.

(Я сам не пробовал это решение, отсюда и «perhapes» и «maybes», но я был в проектах с такими же проблемами, и пытаться пройти через diff с сотнями несущественных изменений - это боль которые не ограничены пробелами, но включают само форматирование.)

Answer 4

Как объяснено в Возможно ли для git-merge игнорировать различия в конце строки? , важнее связать правильный инструмент сравнения с вашей любимой VCS, а не полагаться на правый Опция VCS (даже если у Git есть некоторые опции относительно пробелов, такие как упомянутые в ответ Алана , он всегда будет не таким полным, как хотелось бы).

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

Answer 5

Beyond Compare делает это (и многое другое), и вы можете интегрировать его либо в Subversion, либо в Sourcesafe как внешний инструмент сравнения.

Answer 6

Subversion, очевидно, поддерживает это, либо изначально в последних версиях, либо используя альтернативный diff, такой как Gnu Diff.