Как долго вы должны хранить старый код в своей базе кода? Подрядчики продолжают хранить старый код в базе кода, превращая его в комментарии. Это действительно разочаровывает, и я хочу, чтобы они просто удалили старый код, а не комментировали его.
Есть ли веская причина сохранить старый код в базе кода в качестве комментариев? Я использую контроль версий Visual Sourcesafe
Если вы используете что-то вроде SVN или CVS, нет. Я бы стереть их в поле зрения. Они делают код менее читаемым.
Комментарии должны быть там, чтобы помочь программисту, который читает код, объясняет материал и т.д.
Действительная причина, о которой я могу думать, - это (вымышленный) пример:
# removed the following test because this should work now that bug #12345 is fixed.
#assert a != 0
b = number / a
В принципе, чтобы другие разработчики не вставляли код, который был удален по какой-либо причине.
Сообщите подрядчикам прекратить это делать. Это ужасная практика.
На самом деле нет никакой причины хранить старый код в базе кода; это просто мешает. Ваша система контроля версий покажет вам историю каждого файла.
Единственная возможная причина для хранения старого кода, возможно, для исторической ссылки (возможно, если старый код сделал что-то особенно странное, что может быть актуальным для текущей ситуации).
Иногда я просто прокомментирую код, зная, что я вношу временное изменение (временным я имею в виду менее нескольких дней) и, безусловно, планирую вернуться к нему.
edit: другая связанная практика ставит имена и даты изменений в файле:
// 06/20/2009 - joe changed this #1245
Не делай этого. В то время казалось бы ценным понять, кто внес изменения, но со временем это действительно не имеет значения, а также загромождает код.
Вы спрашиваете, как долго? Я не обижаюсь, если у меня есть старый код в одном или двух местах, если это горячие точки, где люди все еще работают.
Возможно, они еще не уверены в новом коде. Является ли новый код "выполненным?"? Это написано так, как должно быть? Проходит ли это испытание? Прокомментировано и задокументировано? Является ли производительность там, где она должна быть? (Лучшая причина, по которой я могу думать о том, что старый и новый код обо мне - когда я использую хронирование или профилирование определенного набора случаев.)
Есть ли что-нибудь о старом коде, который предпочтительнее нового кода?
Неужели подрядчики чувствуют себя в спешке? Или это просто старая привычка от контрольных дней до версии?
Если вы используете исходный элемент управления, которым вы должны быть, то удалите старый код, поскольку копия будет в исходном контроле готова и ждет вас, если вам когда-нибудь понадобится добавить его обратно. Наличие старого кода там уменьшит способность читать код, как указано выше, и ввести путаницу. Кроме того, если вы используете подрядчиков для написания своего кода, расскажите им, как закодировать, когда вы платите свою зарплату. Определите стандарты кодирования для них и получите их код по намерениям, которые должны улучшить имя методов, свойств и т.д. И уменьшить необходимость комментировать все вместе.
В принципе, у вас есть только 2 варианта.
В противном случае, вы можете упомянуть только 2 варианта. Ваш звонок!
Когда вы напоминаете подрядчикам, им не нужно прокомментировать код, так как Sourcesafe сохранит историю, спрашивая их, почему они это делают.
Возможно, они почему-то не доверяют ему. Если вы можете получить эту причину, они могут обратить внимание. Я знаю, что когда мы переехали из VSS много лет назад, это было связано с проблемами надежности и масштабируемости, которые они могли бы подвергнуть воздействию. Если вы можете решить их проблемы, либо продемонстрировав, что VSS подходит для ваших нужд, либо заявив, что вы будете исследовать другие решения управления версиями (если у вас есть бюджет для этого, конечно), вы должны выиграть их.
Убеждение лучше, чем принуждение.
Я предполагаю, что вы ссылаетесь на значимые блоки кода, которые, по-видимому, имеют какое-то значение или хорошие алгоритмы сами по себе, а не просто нечетные строки здесь или там.
В этих случаях существует естественная тенденция сохранять код, если вы внесли большие изменения, сохраняя старый, поскольку комментарии действуют как форма обзора кода. Любой, кто получит последнюю версию, сможет мгновенно увидеть большие изменения, которые были сделаны, и если есть проблема, гораздо легче увидеть, что было там. Если проблема связана с новым кодом, то есть очень простой способ мгновенно проверить его.
Итак, учитывая это, я стараюсь прокомментировать старый код для первой ревизии, а затем удалить его только тогда, когда код впоследствии будет изменен снова, к этому моменту изменение будет "вставлено" и вряд ли будет причина ошибок.
Эти комментарии являются формой документации, нет необходимости удалять их для любого пуристического идеала "чистого" кодирования. Удалите их, когда они больше не нужны, сохраните их, пока они могут быть полезными.
Да, давай посмотрим. Это не дает другого значения, чтобы показать, что разработчик, который его прокомментировал, не был уверен в его удалении. Или они не знают, как использовать программное обеспечение для управления версиями.
Так много причин оставить старый код там. В принципе - как только он удаляется, он эффективно ушел - если кто-то на самом деле не помнит, что он был там.
Как злой подрядчик, я не удаляю код, если только не выполняю существенную переработку процедуры - сбрасываю его и заменяю, а не "фиксирую".
Сохранение старого кода просто усложняет чтение кода в целом. Пока существует определенная форма контроля версий для проекта, код с комментариями должен быть удален. Если у вас нет контроля версий и вы не можете установить его, то желательно ставить старый код в файл, не являющийся частью базы кода.
Во-первых, я говорю, избавиться от него.
Но я знаю одну причину: если она еще находится в вашем управлении версиями, это не означает, что кто-то может ее увидеть. Если вам, возможно, придется снова это увидеть, сначала вам нужно знать, что он когда-то существовал. Иногда вы делаете модификацию, которую будущие разработчики должны видеть как старым, так и новым способом, и если вы удалите старый способ, как разработчики знают, что это было когда-то там? Большинство людей не документируют изменения в управлении версиями достаточно хорошо для этой проблемы.
Те, кто говорит, чтобы избавиться от кода с комментариями, потому что инструменты контроля версий решат любую проблему, с которой вы могли столкнуться, являются идиотами.
Вам нужно избавиться от устаревшего кода, ТОЛЬКО ВЫ ПОЛОЖИТЕЛЬНО УВЕРЕНЫ, ЧТО ЭТО ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО ОБОРОМЕТ.
Когда-либо приходилось пересматривать модификацию, потому что "это было не совсем плохо, но, увы, это было не совсем хорошо"? Если вы все еще можете взять источник производства и ЗНАЙТЕ, что предыдущая версия кода все еще там, в какой-то текстовой форме, это сэкономит вам много времени, потому что вам не придется прибегать к сложным, сложным -control и, следовательно, очень простую работу с использованием любых "частичных слияний источников" и "частичной консолидации источников", которые может предложить вам ваш инструмент управления версиями.
Люди, которым не нравится эта реальность, несомненно, должны были потратить всю свою карьеру на создание только кода, который никогда не был "не совсем плохим, но не совсем хорошим", или, другими словами, производя только код, который был либо полностью плохим, либо иначе все идеально. И мы все знаем, насколько велика вероятность достижения последней.
Проект, который я сейчас представляю, использует еще один подход - какой-то компромисс... Когда вы решаете, что некоторая часть кода больше не будет использоваться, вы просто прокомментируете это, напишите дату комментируя, и (если это возможно - например, в Netbeans или VisualStudio), вы вставляете старый код в #region OLD_IMPL. Эффект? - У вас все еще есть старый код на всякий случай - Блок неиспользуемого кода занимает ровно 1 строку (#region OLD_IMPL) - Если вы видите, этот код не используется в течение года (у вас есть дата его комментирования), вы можете просто удалить его.
В случае каких-либо критических ситуаций вы всегда используете SVN;)