Полезно ли писать мертвый код?

Считаете ли вы полезным писать мертвый код?

Кто-то говорит: «Если у вас есть две логики для выполнения какой-либо операции, то вместо комментирования другого логического кода или удаления кода сделайте его мертвым кодом, поскольку это не повлияет на операцию».

Пример:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

Это правда?

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

ИМО, это хуже, чем бессмысленно.

Помимо того, что это пустая трата времени, у вас (или у следующего парня) возникает иллюзия, что у вас есть код, который будет работать, если вы перейдете trueнаfalse . Это всего лишь иллюзия ... если вы не проверите это.

И если конечно, то беспорядок делает код труднее для чтения.

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

Редактировать:

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

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

В конце концов, вы наверняка окажетесь в какой-то форме ада поддержки.

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

Нет, это плохо, потому что это загромождает ваш код и снижает удобство обслуживания.

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

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

Я честно смущен тем, что ты делаешь.

В порядке убывания приоритета:

1. Вы должны вести учет изменений коды где - то так , если новый код не работает, вы можете сравнить их. Это всегда должно быть в системе контроля версий. Я полагаю, вы уже делаете это. Если нет, сделайте все возможное, чтобы получить НЕКОТОРЫЕ формы контроля версий. Если вам абсолютно необходимо обойтись без (и я никогда в своей жизни не слышал о случаях, когда это хорошая идея), по крайней мере, регулярно делайте резервные копии состояния источника, легкодоступного.

2. Предполагая, что вы делаете # 1, так что вы можете восстанавливать мертвый код, если вам нужно, НЕ сохраняйте его в реальном коде в течение длительного времени. Это будет просто сбивать с толку, добавлять дополнительную сложность без всякой ценности, требовать обслуживания, не синхронизироваться с живым кодом и вводить в заблуждение людей в будущем и т. Д., И т. Д.

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

Причина, по которой я полагаю, что люди делают это слишком часто: из-за сомнений (часто правильно), что люди действительно прочитают историю контроля версий, если у них возникнут проблемы; из-за страха новый код не сработает, и вам нужен простой вариант возврата. Компромисс, чтобы попытаться выполнить вас обоих, может заключаться в том, чтобы добавить комментарий «Изменено для расчета ... в (Дата). Если есть какие-либо проблемы, см. Старую версию в системе контроля версий» или подобное.

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

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

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

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

если вы удалите только первое /в первой строке комментария, оно станет:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

При этом вы можете переключаться между альтернативами, просто добавляя или удаляя один / код в коде.

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

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

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Я бы не использовал это таким образом, но это работает.

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

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

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

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

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

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

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

В любом случае у вас не будет мертвого кода.

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

НЕТ

Некоторые программисты используют этот стиль в качестве альтернативы комментариям и считают его элегантным.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

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

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

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

Для будущих изменений кода вы собираетесь проверить, что мертвый код все еще работает? Если нет, избавься от этого.

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

Могут быть причины сохранить закомментированный код (или, в C или C ++, #ifdefисключенный код), но это должно сопровождаться комментариями о том, почему он все еще существует и для какой цели он служит.

Обратите внимание, что в Java следующее даже не скомпилируется из-за недоступного кода:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

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

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

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

Причина, по которой люди комментируют некую старую логику, заключается в том, что они боятся вносить большие изменения в код. И действительно, через неделю понять, что старый код был на самом деле правильным, и теперь вам нужно писать его с нуля, - сука. Но вот для чего нужен контроль версий. Если вы решили изменить логику, не бойтесь потерять несколько работающий настоящий код. Удалите его и пусть ваш SVN / Git / TFS позаботится о создании версий для вас.

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

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

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

Единственное место, где я видел это полезным, это в случаях, когда вы хотите что-то быстро отключить и проверить / засыпать (скажем, программа выполняет шаги A, B, C - все это занимает много времени. Во время засыпки вы можете отключить B и C). на время, чтобы ускорить его, если вы знаете, что они не нужны).
Но правда в том, что во всех случаях это очень хакерски. И если вы видите долгосрочное использование своего кода обратной засыпки, вы должны написать свой код таким образом, чтобы он использовал config для выбора, а не использования таких хаков.
Мое быстрое правило - никогда не проверять такой код. Если вам нужен контроль / контроль версий, это означает, что вы сможете вернуться к этому в ближайшее время, и это всегда плохо в свете меняющихся требований.

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

Чрезвычайно важно, чтобы в сообщении об ошибке было что-то вроде «Паника: мы никогда не должны быть здесь в строке% d в файле% s» ...