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

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

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

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

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

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

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

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

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

Поэтому, учитывая это, я склонен комментировать старый код для первой ревизии, а затем удалять его только тогда, когда код впоследствии изменен снова, к этому времени изменение уже будет «внедрено» и вряд ли станет причиной ошибок.

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

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

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

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

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

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

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

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

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

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

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

Чувствуют ли подрядчики в спешке? Или это просто старая привычка времен до контроля версий?

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

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

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

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

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

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

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

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

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

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

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

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