Комментарий обслуживания

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

Одна вещь, которую я всегда пытаюсь сделать, состоит в том, чтобы вставить идентификатор ошибки (или идентификатор запроса новых функций) в системе отслеживания ошибок в комментариях регистрации кода, которые я делаю для того изменения. Я добавляю, что что-то как "видит комментарии для этой ошибки/функции в Bugzilla для получения дополнительной информации". Там я могу и обычно объяснять объяснение для того изменения кода. Это означает, что все изменения или по крайней мере все важные изменения должны быть прослежены посредством запроса новых функций / идентификатор ошибки. Я много раз создавал ошибку только для объяснения в деталях бизнес-включенных причин.

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

// modified by A.B. on 11/23/99 to fix issue #123456

Я видел комментарии как это в нашей кодовой базе, и они не делают лет смысла по линии. Кто, черт возьми A.B., и каков был выпуск № 123456? Если код все еще здесь, это означает, что кто-то планирует откат этих изменений в будущем?

Эти комментарии не имеют никакого значения и только служат для создания помех коду.

Я предложил бы создать метод и вызов, что из кода, который изменяется.
Кроме того, назовите метод для предложения цели/намерения метода.

например. GiveRebateIfValidCoupon();

"Какие-либо стандарты кодирования/комментария Вы используете при изменении кода?"

Да. Сделайте новые подклассы. Оставьте старый код в покое кроме редкого случая, что Вы не протестировали его правильно и были на самом деле неправы.

Изменения в требованиях означают добавлять подклассы и новые тесты для обработки новых бизнес-правил.

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

Кроме этого, мы полагаемся на управление исходным кодом.

Код должен приспособить любым стандартам кодирования, которые Вы имеете, или Ваша организация имеет.

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

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

Хорошо понять код перед изменением его (между прочим).

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

Иногда я знаю, что определенная функциональность собирается измениться назад и вперед, переместить, изменить имена, и т.д. в зависимости от того, как требования пользователя обсуждены. В этом особом случае я сохраню старую версию там и просто прокомментирую его. Затем это становится тривиальным, чтобы просто не прокомментировать это позже, вместо того, чтобы сильно ударить посредством управления исходным кодом, ища старую версию. Это может также сохранить чью-то задницу, если они должны поддержать Ваш код позже, потому что, когда пользователи передумали СНОВА, требование уже будет в коде, ожидая, чтобы быть непрокомментированным.

Я должен согласиться с большим количеством других людей здесь на ТАК. "Если Вам не нужно что-то в Вашем коде, удалите его". Особенно в производственном коде, последней вещью, которую Вы хотите, является большая помеха. Для кого-то могло быть намного легче выяснить, как Ваши работы изменения, чем считать Ваше обслуживание комментируют и возможно запутываются.

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