Старый код в комментариях [закрыто]
https://stackoverflow.com/questions/1022552
-
06-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Как долго вы должны комментировать старый код в своей базе кода? Подрядчики продолжают хранить старый код в базе кода, превращая его в комментарии. Это действительно расстраивает, и я хочу, чтобы они просто удалили старый код, а не комментировали его.
Есть ли веская причина для сохранения старого кода в базе кода в качестве комментариев? Я использую контроль версий 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
Не делай этого тоже. В то время может показаться ценным видеть, кто внес изменение, но со временем оно действительно не имеет никакого значения и также загромождает код.
Если вы используете систему контроля версий, которой вы должны быть, то удалите старый код, так как копия будет в системе контроля версий готова и ждет вас, если вам когда-нибудь понадобится добавить ее обратно. Наличие старого кода снизит способность читать код, как указано выше, и вводит в заблуждение. Также, если вы используете подрядчиков для написания своего кода, сообщите им, как кодировать, когда вы платите им зарплату. Определите стандарты кодирования для них и включите их в код намеренно, что должно улучшить название методов, свойств и т. Д. И уменьшить потребность в комментариях.
Вы спрашиваете "как долго?" Меня не оскорбляет наличие старого кода в одном или двух местах, если это горячие точки, где люди все еще работают.
Возможно, они еще не уверены в новом коде. Новый код "готов"? Написано так, как должно быть? Это проходит испытания? Это прокомментировано и задокументировано для спецификации? Производительность там, где она должна быть? (Лучшая причина, по которой я могу придумать старый и новый код, - это когда я синхронизирую или профилирую определенный набор случаев.)
Есть ли что-то в старом коде, которое предпочтительнее нового кода?
Чувствуют ли подрядчики спешку? Или это просто старая привычка из предыдущих дней контроля версий?
Когда вы напоминаете подрядчикам, что им не нужно комментировать код, так как Sourcesafe сохранит историю и спросит их, почему они это делают.
Возможно, они почему-то не доверяют. Если вы можете получить эту причину из них, они могли бы обратить внимание. Я знаю, что когда мы перешли с VSS много лет назад, это было связано с проблемами надежности и масштабируемости, которым они также могли подвергаться. Если вы можете решить их проблемы, либо продемонстрировав, что VSS соответствует вашим потребностям, либо сказав, что вы исследуете другие решения по управлению исходным кодом (если у вас, конечно, есть бюджет), вы должны их победить.
Убеждение лучше принуждения.
Ага, взломай его на месте. Это не дает никакой ценности, кроме как показать, что разработчик, который прокомментировал это, либо не был уверен в его удалении. Или они не знают, как использовать программное обеспечение для контроля версий.
По сути, у вас есть только 2 варианта.
<Ол>В противном случае, вышеупомянутые два варианта. Ваш звонок !!
Сохранение старого кода только усложняет чтение кода в целом. Если для проекта существует какая-либо форма контроля версий, закомментированный код следует удалить. Если у вас нет контроля над версиями и вы не можете его настроить, то рекомендуется поместить старый код в файл где-то, не являющееся частью базы кода.
Я предполагаю, что вы ссылаетесь на значимые блоки кода, которые, кажется, имеют определенную ценность, или на хорошие алгоритмы сами по себе, а не только на странную строку здесь или там.
В этих случаях существует естественная тенденция сохранять код, если вы внесли большие изменения, сохранив старый, поскольку комментарии выступают в качестве формы проверки кода. Любой, кто получит последнюю версию, сможет мгновенно увидеть сделанные крупные изменения, и, если возникнет проблема, гораздо легче увидеть, что было раньше. Если проблема в новом коде, то есть очень простой способ мгновенно проверить его.
Итак, учитывая это, я склонен закомментировать старый код для первой ревизии, а затем удалять его только при последующем изменении кода, к этому времени это изменение будет «включено» и вряд ли будет причина ошибок.
Эти комментарии являются формой документации, нет необходимости удалять их для любого пуристского идеала «чистого» кодирования. Удалите их, когда они больше не нужны, сохраняйте их, пока они могут быть полезны.
Во-первых, я говорю избавиться от этого.
Но я знаю одну причину, по которой это не так: хотя она все еще присутствует в вашем контроле версий, это не значит, что кто-то может ее увидеть. Если вам может понадобиться увидеть это снова, вы должны сначала знать, что это когда-то существовало. Иногда вы вносите изменения, чтобы будущие разработчики могли видеть и старый, и новый путь, и если вы удалите старый, как разработчики узнают, что он когда-то был? Большинство людей не достаточно хорошо документируют изменения в управлении версиями для решения подобных проблем.
Так много причин оставить старый код там. По сути - когда он удален, он фактически исчезает, если только кто-то на самом деле не помнит его там.
Как злобный подрядчик, я не удаляю код, если не делаю существенную переписку процедуры - ее удаление и замена, а не " исправление " Это.
В проекте, который я сейчас представляю, используется еще один подход - своего рода компромисс ... Когда вы решаете, что какая-то часть кода больше не используется, вы просто комментируете ее, записываете дату комментирование, и (если это возможно - например, в Netbeans или VisualStudio) вы вставляете старый код в #region OLD_IMPL. Эффект? - У вас все еще есть старый код на всякий случай - Блок неиспользуемого кода занимает ровно 1 строку (#region OLD_IMPL) - Если вы видите, что этот код не используется в течение года (у вас есть дата его комментирования), вы можете просто удалить его.
В любых критических ситуациях вы всегда используете SVN;)
Те, кто говорят, чтобы избавиться от закомментированного кода, потому что инструменты контроля версий решат любую проблему, с которой вы можете столкнуться, являются идиотами.
Вам нужно избавиться от устаревшего кода, ПОСКОЛЬКУ ВЫ ПОЗИТИВНО УБЕДИТЕСЬ, ЧТО ЭТО ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО НАБЛЮДЕНО.
Всегда приходилось пересматривать модификацию, потому что "она была не совсем плохой, но, увы, она тоже была не совсем хорошей". ? Если вы все еще можете извлечь производственный исходный код и ЗНАТЬ, что предыдущая версия кода все еще там, в некоторой текстовой форме это сэкономит вам много времени, потому что вам не нужно прибегать к сложным, трудным для понимания -контроль и, следовательно, очень ошибочные процессы использования любого «частичного слияния источников»; и «частичная консолидация источников»; что ваш инструмент контроля версий может предложить вам.
Люди, которые не любят эту реальность, наверняка потратили всю свою карьеру на то, чтобы создавать только код, который никогда не был «не совсем плохим, но и не совсем хорошим», или, другими словами, производил только код, который был либо совсем плохим. или же совершенно идеально. И все мы знаем, насколько велика вероятность достижения последнего.
