Чи корисно писати мертвий код?

Чи вважаєте ви написання мертвого коду корисним?

Деякі кажуть: "Якщо у вас є 2 логіки, щоб виконати якусь операцію, то замість того, щоб коментувати інший логічний код, коментуючи або видаляючи код, зробіть його мертвим кодом, оскільки це не вплине на операцію".

Приклад: -

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
//*/

Я б не використовував це таким чином, але це працює.

Бувають дуже рідкісні випадки, коли старий код та факт його заміни дійсно повинні залишатися у вихідному коді, щоб майбутніх програмістів попередити про щось, що є протиінтуїтивним. У цьому випадку також потрібен якийсь коментар, в якому пояснюється, чому це все ще є і що сталося.

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

Компілятор буде проігноровано. Однак я згоден з вами і просто видаляю інше твердження. Якщо припустити, що ви використовуєте контроль версій, ви все одно зможете переглянути старий код, переглянувши історію файлу.

Це, мабуть, особиста думка, але я вважаю, що мертвий код відволікає увагу при збереженні фрагмента коду. У будь-якому завданні у вас завжди є кілька способів його виконання, тому ви повинні вибрати один. Проведіть своє дослідження, оцініть алгоритми та оберіть один із них. Після цього коду не потрібно містити в ньому будь-яких альтернативних методів.

Якщо є два дуже сильні претенденти, напишіть невелику примітку про альтернативу та вставте її у вікі проекту чи десь ще, де міститься проектна документація. Якщо ви хочете, ви можете помістити коментар у одному рядку, який посилається на цей документ, та накреслити, чому ви хочете прочитати його.

Я не можу одразу придумати ситуацію, коли мені стало корисно писати мертвий код. Якщо є альтернативні алгоритми, то:

• або ви збережете найкорисніший і усуньте інший,
• або алгоритми застосовні до різних обставин, і тоді ви зберігаєте і те, і умовне ідентифікує обставини, коли ви використовуєте перший алгоритм.

У будь-якому випадку у вас виявиться без мертвого коду.

Якщо ви не видалите або не прокоментуєте свій мертвий код, вам доведеться підтримувати його, щоб уникнути помилок компілятора. Це витрачений час. Просто видаліть його, якщо у вас є 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;
}

В ідеалі, якщо з вашим кодом щось не так, ви хочете знайти його якомога раніше, а не відпускати його до виробництва та знаходити ваші користувачі.

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

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

Причина, через яку люди коментують стару логіку, полягає в тому, що вони бояться внести великі зміни в код. І дійсно, зрозумівши через тиждень, що старий код був насправді правильним, і тепер його потрібно писати з нуля, це сука. Але саме для цього призначений контроль джерела. Якщо ви вирішили змінити певну логіку, не бійтеся втрачати дещо працюючий код. Видаліть його та дозвольте SVN / Git / TFS піклуватися про версію для вас.

Якщо це не так, і ви просто створили дві різні логіки, щоб зробити щось, тому що вам не байдуже YAGNI або DRY, тоді просто переконайтеся, що ви поклали його десь там, де люди зможуть його використовувати. Можливо, киньте туди стратегічну схему, якщо вам це подобається. Тільки не робіть цих речей "якщо .. інше", це поганий дизайн та біль у підтримці. Якщо ви дійсно вважаєте, що якийсь код має право існувати, переконайтеся, що ви можете використовувати його.

Ще один погляд на це полягає в тому, що в основному більшість професійних програмістів сходяться на думці, що розмір коду - ворог. Погляньте на ці повідомлення в блозі: Найкращий код - це зовсім не код Джеффа Етвуда, найгіршого ворога Кодексу Кодеса ​​Стіва Йегге, ви можете знайти ще багато іншого.

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

Єдине місце, що я бачив, як це корисно, - це у тих випадках, коли ви хочете щось вимкнути та перевірити / заповнити (скажімо, програма робить кроки A, B, C - все займає багато часу. Під час заповнення ви можете вимкнути B і C на час прискорити його, якщо ви знаєте, що вони не потрібні).
Але правда полягає в тому, що у всіх випадках це дуже хакі. І якщо ви бачите довгий термін використання свого коду заповнення, вам слід написати свій код таким чином, щоб він використовував конфігурацію для вибору вибору замість таких хаків.
Моє швидке правило про те, що ніколи не перевіряйте такий код. Якщо вам потрібен контроль за реєстрацією / перевіркою версій, це означає, що ви зможете знову повернутися до цього, і це завжди погано зважаючи на зміни вимог.

Власне, є один із способів корисного мати "мертвий" код: коли ви хочете, щоб ваша програма кинула величезний виняток, оскільки вона дійшла до чогось, чого ніколи не повинно було відбутися. Це буде або помилка компілятора, або якщо хтось із рядків змінив логіку в тесті, який ви використовуєте, і прикрутив його. У будь-якому випадку ваш "інший" надсилає феєрверки. У цьому випадку ви хочете вимкнути це для випуску.

Життєво важливо, щоб повідомлення про помилку констатувало щось на кшталт "Паніка: ми ніколи не повинні знаходитись тут у рядку% d у файлі% s" ...