SVN автоматическое форматирование кода при регистрации?
Просто позвольте мне добавить это:
@sprite .myBackground {
gwt-image: "myImage";
/* Additional CSS rules may be added. */
}
становится
.myBackground {
backgroud-image: url(-url of the image-)
width: *width of the image*
height: *height of the image*
}
Не забудьте переопределить их, если вам это нужно: например, установить высоту и ширину в авто:
@sprite .myBackground {
gwt-image: "myImage";
height: auto;
width: auto;
}
HTH, я изо всех сил пытался выяснить это;)
6 ответов
Вы касаетесь земли священной войны. Возиться с форматированием людей - это просят вилы и факелы.
Моя рекомендация: Не .
Не говоря уже о том, что если вы говорите о C #, а ваши разработчики используют Visual Studio, VS имеет множество инструментов для автоматического форматирования. Просто введя эту закрывающую фигурную скобку, VS может / автоматически отформатирует ваш код.
Возможно, лучшим решением будет заставить всех ваших разработчиков использовать одни и те же настройки автоматического форматирования.
Инструменты -> Параметры, Текстовый редактор -> C # -> Форматирование
Эти настройки можно экспортировать, поэтому, если вы можете заставить команду согласиться на использование тех же настроек форматирования кода в VS, вы можете избежать проблем с выполнять это в своей системе управления версиями, которую лучше оставить для того, чтобы делать то, что у нее получается лучше всего.
Если вы одержимы этим, хук перед фиксацией, как говорили другие, - это путь. Если ваш сервер SVN работает под Windows, могу ли я порекомендовать CaptainHook для написания ваших скриптов перехвата? Скрипты с поддержкой подключаемых модулей, которые можно писать на любом языке .NET.
С помощью сценария ловушки перед фиксацией вы могли бы это сделать, да. Но я уверен, что вы удалите этот скрипт после первого коммита, потому что у вас возникнут большие проблемы.
Если вы измените данные, которые будут зафиксированы, клиент об этом не узнает. Таким образом, после такой фиксации, когда ваш скрипт «исправляет» форматирование файла, содержимое файла в репозитории будет отличаться от файлов в вашей рабочей копии. Но ваша рабочая копия все еще думает, что она обновлена с репозиторием (в конце концов, изменения только что зафиксированы).
Так что при следующем обновлении вы попадете в ад - сломанная рабочая копия, рассерженные пользователи, ...
И, конечно, вы можете нарушить сборку - автоматическое форматирование иногда имеет такой эффект.
Конечно, вы можете реализовать сценарий ловушки, который проверяет на правильность форматирования и возвращает ошибку, если это не так. Это прекрасно.
как и большинство людей здесь, я согласен, что добавление ловушки предварительной фиксации, которая переписывает их код, плохо, однако у вас может быть ловушка предварительной фиксации, которая отклоняет код, который не отформатирован в соответствии с вашими методами кодирования и сообщить пользователю о такой ошибке.
Я думаю, вы можете сделать это, используя обработчик предварительной фиксации в вашем репозитории.
Править Людям, которые думают, что это плохая идея (я Я не говорю, что это не так): организации нередко навязывают определенный стиль кода или форматирование кода. Иногда эти правила могут быть довольно педантичными и строго соблюдаемыми, и хотя обычно они связаны с человеческими действиями (например, форматирование до правильного стиля до того, как вы что-либо зафиксируете в репозитории), автоматизация процесса иногда может быть полезной.
Альтернатива подход может заключаться в том, чтобы выполнить проверку автоматически перед фиксацией, но все же разрешить фиксацию, даже если проверка не удалась, а затем отправить только электронное письмо или другое уведомление, чтобы указать, что кто-то не следовал стилю.
Я настоятельно рекомендую его.
Используйте сценарий предварительной фиксации или, еще лучше, найдите способ сделать это автоматически в вашей среде IDE (предварительная фиксация отправит измененный файл клиенту ). Eclipse может автоматически форматировать при сохранении.
Обоснование этого состоит в том, что если разработчики отформатируют иначе, вы найдете файлы, в которых есть коммиты, где фиксация - это всего лишь изменение форматирования, и это вызовет бесконечную путаницу.
Распространенное явление. шаблон форматирования - очень хорошая идея. Это будет сложно представить, но оно того стоит. Все изменения будут настоящими изменениями, а не только изменениями форматирования. По моему опыту, разработчики увидят преимущества и примут их.
Я работал с cvs и java и использовал jalopy для автоматического форматирования. Мы использовали систему ветвления, поэтому она была обязательной и работала очень хорошо.
Это возможно, но это тоже очень и очень плохая идея.
Никакие автоматические форматеры кода не идеальны, и я почти гарантирую, что это вызовет у людей галочку.
Тем не менее , если вы хотите это сделать, попробуйте использовать перехватчики предварительной фиксации.
Сервер SVN работает в системе Windows или Linux? А какой форматер кода вы хотите использовать?