Старый код в комментариях

Ответ 1

Если вы используете что-то вроде SVN или CVS, нет. Я бы стереть их в поле зрения. Они делают код менее читаемым.

Комментарии должны быть там, чтобы помочь программисту, который читает код, объясняет материал и т.д.

Ответ 2

Действительная причина, о которой я могу думать, - это (вымышленный) пример:

# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a

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

Ответ 3

Сообщите подрядчикам прекратить это делать. Это ужасная практика.

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

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

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

edit: другая связанная практика ставит имена и даты изменений в файле:

// 06/20/2009 - joe changed this #1245

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

Ответ 4

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

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

Есть ли что-нибудь о старом коде, который предпочтительнее нового кода?

Неужели подрядчики чувствуют себя в спешке? Или это просто старая привычка от контрольных дней до версии?

Ответ 5

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

Ответ 6

В принципе, у вас есть только 2 варианта.

• Удалить его - это когда вы используете некоторый репозиторий кода. Ваш репозиторий расскажет вам, какие изменения были внесены, поэтому вам не нужно хранить давние комментарии в рабочем коде, что не объясняет что-то на простом языке.
• С другой стороны, если вы хотите сохранить этот код по нескольким причинам, например, я сохранил код вычисления с плавающей точкой в ​​своем приложении, потому что он не работал над платформой, для которой я программировал. Но поскольку я бы не хотел, чтобы мое приложение оставалось ограниченным этой платформой, я сохранил код там, поэтому он сохраняет усилия, когда я переношу приложение на платформу, которая поддерживает вычисления с плавающей запятой. Это лишь одна из причин сохранения старого кода и может быть применима к людям того же уровня.

В противном случае, вы можете упомянуть только 2 варианта. Ваш звонок!

Ответ 7

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

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

Убеждение лучше, чем принуждение.

Ответ 8

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

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

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

Во-первых, я говорю, избавиться от него.

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

Ответ 13

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

Вам нужно избавиться от устаревшего кода, ТОЛЬКО ВЫ ПОЛОЖИТЕЛЬНО УВЕРЕНЫ, ЧТО ЭТО ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО ОБОРОМЕТ.

Когда-либо приходилось пересматривать модификацию, потому что "это было не совсем плохо, но, увы, это было не совсем хорошо"? Если вы все еще можете взять источник производства и ЗНАЙТЕ, что предыдущая версия кода все еще там, в какой-то текстовой форме, это сэкономит вам много времени, потому что вам не придется прибегать к сложным, сложным -control и, следовательно, очень простую работу с использованием любых "частичных слияний источников" и "частичной консолидации источников", которые может предложить вам ваш инструмент управления версиями.

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

Ответ 14

Проект, который я сейчас представляю, использует еще один подход - какой-то компромисс... Когда вы решаете, что некоторая часть кода больше не будет использоваться, вы просто прокомментируете это, напишите дату комментируя, и (если это возможно - например, в Netbeans или VisualStudio), вы вставляете старый код в #region OLD_IMPL. Эффект? - У вас все еще есть старый код на всякий случай - Блок неиспользуемого кода занимает ровно 1 строку (#region OLD_IMPL) - Если вы видите, этот код не используется в течение года (у вас есть дата его комментирования), вы можете просто удалить его.

В случае каких-либо критических ситуаций вы всегда используете SVN;)