Czy pisanie martwego kodu jest przydatne?

Czy przydatne jest pisanie martwego kodu?

Niektórzy mówią: „Jeśli masz 2 logiki do wykonania jakiejś operacji, zamiast komentować inny kod logiczny lub usuwać kod, uczyń go martwym kodem, ponieważ nie wpłynie to na operację”.

Przykład:-

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

Czy to prawda?

Zwykle nie piszę martwych kodów, po prostu usuwam drugą logikę.

IMO jest gorsze niż bezcelowe.

Oprócz tego, że to strata czasu, daje ci (lub następnemu facetowi) złudzenie, że masz jakiś kod, który zadziała, jeśli zmienisz się truena false. To tylko złudzenie ... chyba że je przetestujesz.

A jeśli oczywiście, to bałagan sprawia, że ​​kod jest trudniejszy do odczytania.

Jeśli używasz dowolnego typu SCM, martwy kod jest rzadko przydatny. Zamiast tego powinieneś go usunąć i jeśli kiedykolwiek będziesz potrzebować zobaczyć kod dla logiki 2, pobierz go z repozytorium SCM.

Edytować:

Jeśli masz martwy kod i utrzymujesz inne części kodu, możesz spróbować użyć jakiegoś kodu, który może spowodować wyświetlenie martwego kodu. Jeśli ktoś wykonuje konserwację, może nie znać jej faktycznie martwego kodu, a nawet jeśli to zrobi, z pewnością nie będzie wiedział, dlaczego nadal istnieje.

Jeśli następnie stwierdzisz, że metoda może zostać usunięta, ponieważ nie jest używana przez „żywy” kod, ale tylko przez martwy kod, musisz albo zmienić (i najprawdopodobniej złamać) martwy kod lub uczynić inną metodę martwym kodem.

W końcu z pewnością znalazłbyś się w jakiejś formie piekielnego utrzymania.

Dlatego najlepszym kodem jest kod usunięty, ponieważ nie może on generować błędnych wyników ani rozpraszać opiekunów. :)

Nie, to źle, ponieważ zaśmieca twój kod i zmniejsza łatwość konserwacji.

Zwykle istnieje wyraźny powód, aby preferować jedną z alternatywnych „logiki”. Ten powód (i istnienie odrzuconej alternatywy) należy udokumentować w komentarzu do kodu. W stosunkowo mało prawdopodobnym przypadku, gdy przyczyna stanie się nieważna, kod alternatywny można odzyskać z historii repozytorium (jeśli było to wcześniej preferowane, wdrożone rozwiązanie) lub rozwinąć i wdrożyć, korzystając z pełnej aktualnej wiedzy i wymagań (jeśli jest to po prostu niejasne pomysł).

Nie wpływa na działanie, ale wpływa na konserwację. Chcesz zachować jak najbardziej uporządkowany kod, aby ułatwić jego utrzymanie.

Jestem szczerze zdezorientowany tym, co robisz.

W kolejności malejącej priorytetu:

1. Powinieneś gdzieś przechowywać zmiany w kodzie, więc jeśli nowy kod nie działa, możesz je porównać. Powinno to zawsze podlegać kontroli źródła. Zakładam, że już to robisz. Jeśli nie, zrób wszystko, aby uzyskać NIEKTÓRE formy kontroli źródła. Jeśli absolutnie musisz się obejść (a ja nigdy w życiu nie słyszałem o okazji, kiedy jest to dobry pomysł), przynajmniej regularnie wykonuj kopie zapasowe stanu źródła.

2. Zakładając, że robisz numer 1, aby w razie potrzeby odzyskać martwy kod, NIE przechowuj go w kodzie na żywo. Będzie to po prostu mylące, doda dodatkową złożoność bez wartości, będzie wymagało konserwacji, zsynchronizuje się z kodem na żywo i wprowadzi w błąd ludzi w przyszłości itp.

3. To powiedziawszy, istnieją szczególne sytuacje, w których przełączanie w czasie kompilacji między dwiema ścieżkami kodu jest uzasadnione. Podczas opracowywania nowego kodu, a zaraz potem może się zdarzyć, że oba będą dostępne, więc możesz łatwo przełączać się między nimi. Jeśli prawdopodobnie będziesz musiał wrócić lub dodać opcję konfiguracji zewnętrznej, opcja if oparta na stałej daje im rozsądną ścieżkę aktualizacji. Podobnie jak wiele rzeczy - jeśli rozwiązuje konkretny problem, zrób to. Jeśli nie, unikaj go.

Powodem, dla którego zakładam, że ludzie robią to za dużo, jest: wątpienie (często poprawnie), że ludzie faktycznie przeczytają historię kontroli źródła, jeśli mają problem; przed przestraszeniem nowy kod nie będzie działał i nie będzie potrzeby łatwej zmiany wersji. Kompromisem w próbie spełnienia obojga może być umieszczenie komentarza „Zmieniono, aby obliczyć ... w dniu (Data). W razie problemów zobacz starą wersję w kontroli źródła” lub podobny.

Nie, to nie jest przydatne. Ten elseblok nie spełnia żadnego celu. Jeśli nie masz pewności, której implementacji użyć, skomentuj ją, utwórz oddzielne klasy lub zapisz w innym miejscu. Ponadto przeważnie masz - lub przynajmniej powinieneś - lokalną lub zdalną historię swoich plików źródłowych.

Martwy kod powinien zostać usunięty przez kompilator, jeśli warunek zależy od stałej czasowej kompilacji, więc technicznie nie zaszkodzi to zachować. Jednak wolę raczej komentować, ponieważ poprawia to czytelność kodu.

Jeśli chcesz szybko przełączać się między dwiema alternatywami kodu, możesz użyć następującej wygodnej konstrukcji komentarza:

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

jeśli usuniesz tylko pierwszy /z pierwszego wiersza komentarza, stanie się on:

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

Dzięki temu możesz przełączać się między alternatywami, po prostu dodając lub usuwając jeden /z kodu.

Na początku może to wyglądać trochę dziwnie, ale kiedy się przyzwyczaisz, łatwo rozpoznasz to jako wzór.

Możesz nawet połączyć to w łańcuch, a tym samym przełączać wiele bloków jednocześnie za pomocą jednego znaku:

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

Nie użyłbym tego w ten sposób, ale działa.

Są bardzo rzadkie przypadki, gdy stary kod i fakt, że został zastąpiony, naprawdę powinien pozostać w kodzie źródłowym, aby przyszli programiści byli ostrzegani o czymś, co jest sprzeczne z intuicją. W takim przypadku należy również dodać komentarz wyjaśniający, dlaczego nadal tam jest i co się stało.

Jak zawsze, pisanie łatwych w utrzymaniu programów polega na tym, aby uczynić wszystko bardziej zrozumiałym, a nie tylko przestrzegać twardych i szybkich zasad. Jeśli pozostawienie martwego kodu ułatwia zrozumienie, co się dzieje, zostaw go. Jeśli nie, wyjmij go.

Zostanie zignorowany przez kompilator. Jednak zgadzam się z tobą i po prostu usunę zdanie else. Zakładając, że używasz kontroli wersji, nadal będziesz mógł zobaczyć stary kod, przeglądając historię pliku.

Jest to prawdopodobnie osobista opinia, ale martwy kod rozprasza mnie przy utrzymywaniu fragmentu kodu. Do każdego zadania masz zawsze więcej niż jeden sposób, aby je wykonać, więc musisz wybrać jeden. Przeprowadź badania, oceń algorytmy i wybierz jeden. Po tym kod nie musi zawierać żadnych alternatywnych metod.

Jeśli jest dwóch bardzo silnych pretendentów, napisz krótką notatkę na temat alternatywy i umieść ją na wiki projektu lub w innym miejscu zawierającym dokumentację projektu. Jeśli chcesz, możesz umieścić komentarz w jednym wierszu, który odnosi się do tego dokumentu, i wyjaśnia, dlaczego warto go przeczytać.

Nie mogę od razu pomyśleć o sytuacji, w której pisanie martwego kodu przydało się. Jeśli istnieją alternatywne algorytmy, to:

• albo zachowujesz najbardziej użyteczny, a drugi eliminujesz,
• lub algorytmy mają zastosowanie do różnych okoliczności, a następnie zachowujesz oba, a warunek identyfikuje okoliczności, gdy używasz pierwszego algorytmu.

W obu przypadkach skończysz bez martwego kodu.

Jeśli nie usuniesz ani nie skomentujesz swojego martwego kodu, będziesz musiał go zachować, aby uniknąć błędów kompilatora. To zmarnowany czas. Po prostu usuń go, jeśli masz SCM.

NIE

Niektórzy programiści używają tego stylu jako alternatywy dla komentarzy i uważają go za elegancki.

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

Prosta odpowiedź brzmi: nie. Martwy kod przyciąga zamieszanie i umożliwia pojawienie się błędów. Gdy tylko wpiszesz znak w kodzie, istnieje ryzyko. Więc nie dodawaj więcej niż musisz.

Kiedyś musiałem napisać coś podobnego jako obejście błędu kompilatora, producent kompilatora zalecił nawet użycie tego rozwiązania.

Czy testujesz martwy kod, który piszesz? Zrób coś, aby potwierdzić, że prawdopodobnie jest to dobre? Jeśli nie, pozbądź się tego.

Czy w przypadku przyszłych zmian kodu sprawdzisz, czy martwy kod nadal działa? Jeśli nie, pozbądź się tego.

Nie chcesz złego kodu w swoich programach, nawet jeśli nie jest używany. Posiadanie go sugeruje, że można go używać. Zwykle nie chcesz utrzymywać dwóch wersji kodu, jeśli nie używasz obu, ponieważ jest to dodatkowa praca, a ponieważ wydaje się bezcelowa, większość ludzi nie wykona dobrej roboty na martwym kodzie.

Mogą istnieć powody, aby zachować komentarz bez kodu (lub, w C lub C ++, #ifdefwyedytowany kod), ale należy temu towarzyszyć komentarze, dlaczego wciąż istnieje i do czego służy.

Zauważ, że w Javie następujące kompilacje nie będą nawet kompilowane z powodu nieosiągalnego kodu:

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

Idealnie, jeśli coś jest nie tak z twoim kodem, chcesz go znaleźć tak wcześnie, jak to możliwe, zamiast pozwolić mu przejść do produkcji i zostać znalezionym przez użytkowników.

Jeśli kompilator może znaleźć klasę błędu, pozwól kompilatorowi ją znaleźć. IMHO, co ktoś robi, pisząc martwy kod w opisany przez ciebie sposób, próbuje ominąć ten błąd kompilatora, pozwalając na pojawienie się wszelkich problemów, które może powodować pojawianie się w czasie wykonywania.

Możesz argumentować, że nie można dotrzeć do martwego kodu, więc nie może powodować problemów, ale coś może pójść nie tak w komentowaniu, odświeżaniu i wcięciach, które mogą do tego doprowadzić.

Powodem, dla którego ludzie komentują starą logikę, jest to, że boją się wprowadzić duże zmiany w kodzie. I rzeczywiście, tydzień później uświadomienie sobie, że stary kod był właściwie poprawny i teraz trzeba go napisać od zera, jest suką. Ale po to jest kontrola źródła. Jeśli zdecydujesz się zmienić logikę, nie bój się stracić nieco działającego obecnego kodu. Usuń go i pozwól, aby Twój SVN / Git / TFS zajął się wersjonowaniem dla Ciebie.

Jeśli tak nie jest, a ty po prostu stworzyłeś dwie różne logiki, aby coś zrobić, ponieważ nie obchodzi Cię YAGNI lub SUCHO, po prostu upewnij się, że umieściłeś je w miejscu, w którym ludzie mogą z niego korzystać. Może rzuć tam wzór strategii, jeśli masz na to ochotę. Po prostu nie rób tych rzeczy „jeśli… inaczej”, to zły projekt i trudny do utrzymania. Jeśli naprawdę uważasz, że jakiś kod ma prawo istnieć, upewnij się, że możesz go użyć.

Inne spojrzenie na to jest takie, że w zasadzie większość profesjonalnych programistów zgadza się, że rozmiar kodu jest wrogiem. Spójrz na te wpisy na blogu: najlepszy kod to w ogóle żaden kod , Jeff Atwood, najgorszy wróg Code autorstwa Steve'a Yegge, można znaleźć znacznie więcej.

Ludzie robią wiele rzeczy, aby zachować zwięzłość kodu i zapobiec zbytniej rozbudowie bazy kodu, często nawet przez poświęcenie wydajności (tam, gdzie nie ma to większego znaczenia). Czy naprawdę uważasz, że 100 linii martwego kodu może być dobrą rzeczą?

Jedynym miejscem, w którym widziałem, że jest to przydatne, są przypadki, w których chcesz szybko wyłączyć coś i przetestować / wykonać zasypkę (Powiedz, że program wykonuje kroki A, B, C - wszystko zajmuje dużo czasu. Podczas wypełniania zapasowego możesz wyłączyć B i C na razie, aby przyspieszyć, jeśli wiesz, że nie są konieczne).
Ale prawda jest taka, że ​​we wszystkich przypadkach jest to bardzo hacking. A jeśli widzisz długoterminowe użycie kodu zapasowego, powinieneś napisać swój kod w taki sposób, aby używał config, aby wybrać opcję zamiast używać takich hacków.
Moją szybką regułą jest to, że nigdy nie sprawdzam tego rodzaju kodu. Jeśli potrzebujesz kontroli meldowania / kontroli wersji, oznacza to, że wkrótce będziesz mógł do niej wrócić, a to zawsze jest złe w świetle zmieniających się wymagań.

W rzeczywistości istnieje jeden sposób, w jaki warto mieć „martwy” kod: gdy chcesz, aby Twój program zgłosił ogromny wyjątek, ponieważ osiągnął coś, co nigdy nie powinno się wydarzyć. Byłby to błąd kompilatora lub gdyby ktoś w linii zmienił logikę w używanym teście i spieprzył ją. Tak czy inaczej, Twoje „else” wysyła fajerwerki. W takim przypadku warto go wydać.

Jest niezwykle ważne, aby komunikat o błędzie zawierał komunikat „Panika: nigdy nie powinniśmy być tutaj w wierszu% d pliku% s” ...