Проверка исходного кода Комментарии в верхней части исходных файлов
Я заметил несоответствие с некоторыми исходными файлами в нашей системе, когда некоторые содержат комментарии проверки исходного кода, а некоторые нет. Эти комментарии автоматически добавляются в начало файла, когда он отмечен:
* $Log: //vm1/Projects/Morpheus/Sleep.bdy-arc $
--
-- Rev 1.14 Apr 14 2009 15:32:52 John Smith
--Fixed bugs 2292 and 2230.
Кажется, это было довольно распространенным во всех компаниях, с которыми я работал, но я должен признаться, что изо всех сил стараюсь понять суть. Обычно комментарии не так хороши, их часто оставляют люди, которые давно ушли, и даже когда они соответствуют высоким стандартам, их трудно связать с физическими изменениями кода.
Меня также поразило, что вы физически изменяете файл, который вы регистрируете. Теперь это может быть не такой проблемой с файлами, которые будут скомпилированы, но может быть катастрофой для других, например, файлов JavaScript.
Так что, на самом деле, мой вопрос заключается в том, что послужило мотивацией для предоставления этой функциональности в первую очередь? Кто-нибудь на самом деле находит эти комментарии полезными?
Кроме того, мне было бы интересно узнать, поддерживается ли эта функция в системах контроля версий. Я знаю об этом с PVCS, VSS и Subversion ( Subversion Keyword Substitution), однако мне интересно, доступна ли она и в некоторых из наиболее популярных DVCS.
Ваша помощь, как всегда, высоко ценится.
3 ответа
Вы правы - это, в конечном счете, не очень полезная особенность систем контроля версий! Да, компаниям нравится контрольный журнал, но это обеспечивается командой log системы контроля версий; да, это означает, что журнал доступен, если нет системы контроля версий, но в этом случае Fixed bug 1234 вероятно, не очень значимый:-) И, как вы намекаете, чтобы связать изменения с конкретными строками, вам все равно нужна помощь системы контроля версий.
Вы также правы, что изменение файла во время его фиксации может вызвать проблемы - я однажды видел проблему, когда коллега тщательно следил за тем, чтобы его код компилировался, а затем фиксировал его, только для того, чтобы его воспламенили, потому что файлы, которые он зафиксировал, не сделали. не компилировать. Оказалось, что комментарий был чем-то вроде Clean up /tmp/*.txtи компилятор C лечил /* как символ начала комментария (и жалуется, потому что он уже был внутри комментария).
Еще одна проблема с журналами в файлах заключается в том, что они имеют смысл только для линейной работы - если вы разрабатываете с несколькими ветвями (так, как поощряют распределенные исходные инструменты, такие как git/mercurial/bazaar), наличие журнала в самом исходном файле только служит создавать конфликты слияния почти все время.
По этой причине современные инструменты, как правило, не реализуют эту функциональность. На самом деле Subversion этого не делает - подстановка ключевых слов намеренно не позволяет включать историю журнала.
Так что, на самом деле, мой вопрос заключается в том, что послужило мотивацией для предоставления этой функциональности в первую очередь? Кто-нибудь на самом деле находит эти комментарии полезными?
Когда источники зеркалируются во внешнее местоположение (пакеты исходного кода, индекс исходного кода и т. Д.), Информация об управлении версиями может быть недоступна. Для таких случаев эта информация может быть полезна.
Так что, на самом деле, мой вопрос заключается в том, что послужило мотивацией для предоставления этой функциональности в первую очередь? Кто-нибудь на самом деле находит эти комментарии полезными?
В некоторых компаниях контроль аудита является серьезной проблемой. Аудиторы хотят иметь возможность отслеживать от системы инцидентов до фактических изменений кода. Fixed bugs 2292 and 2230. обеспечивает трассировку от кода к инцидентной системе.
По той же причине некоторые компании требуют номер инцидента как часть комментариев в журнале изменений управления версиями.