Комментарий кодирует, который удален [закрытый]

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

Я также думаю, что это - ужасное предложение:)

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

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

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

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

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

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

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

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

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

Немного истории, для забавы: Я был в компании, несколько лет назад, не зная ничего из управления версиями исходного кода (они получили такой инструмент позже...).
, Таким образом, у них было правило в наших источниках C: "когда Вы вносите изменение, отключаете старый код с макросами препроцессора":

#ifdef OLD /* PL - 11/10/1989 */
void Buggy()
{
// ...
}
#else
void Good()
{
// ...
}
#end

Никакая потребность сказать, наши источники быстро стали нечитабельными! Это был кошмар для поддержания...
Вот почему я добавил к SciTE возможность перейти между вложенным #ifdef / #else / #end и таким... Это может быть все еще полезно в более регулярных случаях.
Позже, я записал макрос Visual Studio для счастливого избавлений от старого кода, как только мы получили наш VCS!

Теперь, как buti-oxa, когда-то я чувствовал потребность указать, почему я удалил некоторый код. По той же причине, или потому что я удаляю старый код, который я чувствую, больше не необходим, но я не слишком уверен (наследие, наследие...). Очевидно, не во всех случаях!
я не оставляю такой комментарий, на самом деле, но я могу понять потребность.
В худшем, я прокомментировал бы в одной версии и удалил бы все в следующей версии...
На моей текущей работе, для важных локальных изменений, мы оставляем старый код, но можем повторно активировать его свойствами в случае крайней необходимости. После тестирования его некоторое время в производстве мы в конечном счете удаляем старый код.

, Конечно, комментарии VCS являются наилучшим вариантом, но когда изменение является несколькими строками в большом файле с другими изменениями, ссылание на небольшое удаление может быть трудным...

Это - одно из тех "разбитых" окон thinkgs как подсказки/предупреждения компилятора, оставленные необращенными. это причинит Вам боль один день, и это способствует небрежности в команде.

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

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

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

не замусорили активный код мертвым кодом.

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

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

Как все вещи, хотя, я думаю, что создание оператора 'All deleted code will ALWAYS be removed' является неправильным подходом.

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

Доверие источнику, отслеживающему, очевидно, не дает это.

Так, я полагаю, что корректный ответ:

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

Если Вы удаляете код. Вы не должны комментировать его, что Вы удалили его. Это - вся цель управления исходным кодом (Вы используете управление исходным кодом? Право?), и как Вы заявляете, комментарий просто загромождает код.

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

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

, Таким образом, я пробую, комментирует мой код энергично. Если некоторый код будет удален по довольно очевидной причине, я не потружусь комментировать удаление. Но если часть кода удаляется по тонкой причине (например, это выполнило функцию, которая теперь обрабатывается различным потоком), я прокомментирую или удалю код и добавлю комментарий баннера почему:

   // this is now handled by the heartbeat thread
   // m_data.resort(m_ascending);

Или:

   // don't re-sort here, as it is now handled by the heartbeat thread

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

   cutoff = m_previous_cutofftime;

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

   cutoff = (!ok_during) ? m_previous_cutofftime : 0;

, Конечно, другая несвязанная проблема подошла, который, оказалось, коснулся той же строки кода в этом случае, возвращающемся ее назад к его исходному состоянию. Таким образом, новая проблема была теперь устранена, но старая проблема внезапно стала повторно поврежденной. D'oh!

Поэтому теперь зарегистрированный код похож на это:

   // this works for overlong events but not resuming
// cutoff = m_previous_cutofftime;
   // this works for resuming but not overlong events
// cutoff = (!ok_during) ? m_previous_cutofftime : 0;
   // this works for both
   cutoff = (!resuming || !ok_during) ? m_previous_cutofftime : 0;

, Конечно, YMMV.

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