Комментарии числа ошибки [закрываются]

Этот тип комментария очень полезен: что происходит, когда Вы изменяете инструменты отслеживания ошибок или управления исходным кодом? Ссылка на BZ1722 по сравнению с FB3101 сказала бы Вам что, отследив инструмент для проверки (Bugzilla или FogBugz, например).

Мне не нравится этот вид граффити. Как другие неприятные формы жизни они срастаются со временем, дросселируя кодовую базу.

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

Это - хорошая вещь!

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

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

Вы попадаете в точку с "уместностью, является очень недолгим, и они имеют тенденцию создавать замусоривание кодовой базы".

Каждый бит бесполезного хлама, который растет в исходных файлах, делает их немного менее читаемыми и трудными поддержать. Удалите все, что не увеличивает стоимость. "Ошибка 12345" имеет мало значения теперь и не будет иметь ни одного через несколько недель.

Мы работаем в крупном масштабе система со многими разработчиками и несколькими выпущенными ответвлениями.

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

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

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

Я сделал это вплоть до Visual Studio 2008, поставленный с аннотацией. Это было полезно при оглядывании назад на старый код, чтобы сразу видеть, что там, по крайней мере, думался позади конкретного решения кода.

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

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

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

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

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

То, что я действительно нахожу полезными, использует дефектный идентификатор в качестве части имени на автоматизированных тестах:

[TestFixture]
public class Release_1_2_Bugfixes
{
  [Test]
  public void TestBug42()
  {
    Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything());
  }
}

Я видел другие проекты делать то же самое.

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

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

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

Править: Я обращаюсь конкретно к помещению их с блоком кода, который необычен или нужен в дополнительном контексте. Это не полезно или необходимо прокомментировать, что каждая опечатка фиксирует Вас, делают :-)

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

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

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

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

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

P.S. Вы могли бы считать эту статью о MS Office от Joel На программном обеспечении полезной. Насколько я знаю код MS Office, и MS Windows полна подобных комментариев, которые объясняют решения, принятые разработчиками, которых долго уводят.

Вы никогда не должны добавлять просто число ошибки. Необходимо добавить число ошибки и предмет и любые спецификаторы при создании нескольких checkins для единственной ошибки:

Ошибка 1111 - Нечто, арестованное в системах на 64 бита. Зафиксируйте № 2, потому что он был вновь открыт после слияния для транкинга.

Некоторые системы имеют интеграцию числа ошибки. В mxr.mozilla.org число ошибки в дисплее журнала cvs автоволшебно превращено в ссылку на число bugzilla.mozilla.org. При закапывании кода это - огромное средство экономии времени. Я думаю, что Fogbugz имеет подобную функцию...

Кроме того, даже если Ваша система не делает, она часто помогает, потому что никто не хочет видеть весь контекст изменения в комментариях, для именно это средство отслеживания ошибки.

Предположите, что у Вас есть новая ошибка, которую Вы разыскиваете к изменению в пересмотре 12345. Вы смотрите на журналы, и это сразу говорит Вам, что Ошибка 1024 была причиной, которая было внесено изменение.

Можно затем пойти и посмотреть 1024 для наблюдения то, что, почему и когда прежде, чем сделать новую фиксацию - 'одна для управления их всех'.

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

Чистая лень. Несомненно, требуется больше времени в конечном счете, но вскоре "//Ошибка 1024" не прилагает усилий вообще. Чем больше кода Вы имеете, тем хуже это.

Я думаю, что это - случай, у "Меня есть молоток, который должен быть гвоздем". Ваш текстовый редактор или IDE не являются Вашим единственным инструментом для управления кодом.

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

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

В конечном счете я думаю, что это - плохая практика. Лучше включать, почему ошибка существует (foos типа Y, не имеют свойства Z). Можно включать "больше в BugId 12345" наряду с этим, если Вы хотите.

Если Вы интегрируетесь на нескольких уровнях, представление исходного кода в trac может связаться непосредственно с BugId.