Czy „złam” i „kontynuuj” złe praktyki programowania?

Mój szef utrzymuje wspomnieć nonszalancko, że złe programiści używać breaki continuew pętli.

Używam ich cały czas, ponieważ mają sens; pozwól, że pokażę ci inspirację:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

Chodzi o to, że najpierw funkcja sprawdza, czy warunki są poprawne, a następnie wykonuje rzeczywistą funkcjonalność. IMO to samo dotyczy pętli:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

Myślę, że to ułatwia czytanie i debugowanie; ale nie widzę też wad.

Kiedy są używane na początku bloku, gdy wykonywane są pierwsze kontrole, działają jak warunki wstępne, więc dobrze.

Kiedy są używane w środku bloku, z pewnym kodem, działają jak ukryte pułapki, więc jest źle.

Możesz przeczytać artykuł Donalda Knutha Programowanie strukturalne z 1974 r., Przejdź do Oświadczeń , w których omawia różne zastosowania tych, go toktóre są strukturalnie pożądane. Obejmują one odpowiednik instrukcji breaki continue(wiele z tamtejszych zastosowań go tozostało opracowanych w bardziej ograniczone konstrukcje). Czy twój szef nazywa Knutha złym programistą?

(Podane przykłady mnie interesują. Zazwyczaj breaki continuenie podobają im się osoby, które lubią jedno wejście i jedno wyjście z dowolnego fragmentu kodu, a taka osoba również marszczy brwi w związku z wieloma returnstwierdzeniami.)

Nie wierzę, że są źli. Pomysł, że są źli, pochodzi z dni programowania strukturalnego. Jest to związane z pojęciem, że funkcja musi mieć jeden punkt wejścia i jeden punkt wyjścia, tj. Tylko jeden returnna funkcję.

Ma to sens, jeśli twoja funkcja jest długa i jeśli masz wiele zagnieżdżonych pętli. Jednak twoje funkcje powinny być krótkie i powinieneś zawijać pętle i ich ciała w ich krótkie funkcje. Ogólnie rzecz biorąc, wymuszenie, aby funkcja miała jeden punkt wyjścia, może spowodować bardzo skomplikowaną logikę.

Jeśli twoja funkcja jest bardzo krótka, jeśli masz pojedynczą pętlę lub, w najgorszym wypadku, dwie zagnieżdżone pętle, a jeśli treść pętli jest bardzo krótka, to jest bardzo jasne, co robi a breaklub a continue. Oczywiste jest również, co robi wiele returninstrukcji.

Zagadnienia te zostały omówione w „Czystym kodzie” Roberta C. Martina oraz w „Refaktoryzacji” Martina Fowlera.

Źli programiści mówią absolutnie (tak jak Sith). Dobrzy programiści używają najczystszych możliwych rozwiązań ( wszystkie inne rzeczy są równe ).

Używanie często przerywania i kontynuowania utrudnia przestrzeganie kodu. Ale jeśli ich zastąpienie sprawia, że ​​kod jest jeszcze trudniejszy do naśladowania, to jest to zła zmiana.

Podany przykład jest zdecydowanie sytuacją, w której przerwy i kontynuacje powinny zostać zastąpione czymś bardziej eleganckim.

Większość ludzi uważa, że ​​to zły pomysł, ponieważ zachowanie nie jest łatwe do przewidzenia. Jeśli czytasz ten kod i widzisz, while(x < 1000){}że zakładasz, że będzie on działał do x> = 1000 ... Ale jeśli są przerwy w środku, to nie jest to prawdą, więc nie możesz naprawdę ufać swojemu zapętlenie ...

To ten sam powód, dla którego ludzie nie lubią GOTO: pewnie, można go dobrze używać, ale może także prowadzić do godawful kodu spaghetti, w którym kod przeskakuje losowo z sekcji do sekcji.

Dla mnie, gdybym miał zrobić pętlę, która przerwała więcej niż jeden warunek, zrobiłbym while(x){}wtedy X przełączając na false, gdy musiałem się wyrwać. Ostateczny wynik byłby taki sam, a każdy czytający kod wiedziałby, aby przyjrzeć się bliżej rzeczom, które zmieniły wartość X.

Tak, możesz [ponownie] pisać programy bez instrukcji break (lub wraca ze środka pętli, które robią to samo). Ale może być konieczne wprowadzenie dodatkowych zmiennych i / lub powielanie kodu, które zwykle utrudniają zrozumienie programu. Z tego powodu Pascal (język programowania) był bardzo zły, szczególnie dla początkujących programistów. Twój szef zasadniczo chce, żebyś programował w strukturach kontrolnych Pascala. Gdyby Linus Torvalds był w twoich butach, prawdopodobnie pokazałby szefowi środkowy palec!

Jest wynik informatyki zwany hierarchią struktur kontrolnych Kosaraju, która sięga 1973 roku i jest wspomniana w (bardziej) znanym artykule Knutha na temat gotos z 1974 roku. ). S. Rao Kosaraju udowodnił w 1973 r., Że nie jest możliwe przepisanie wszystkich programów, które mają wielopoziomowe podziały głębokości n na programy o głębokości przerwania mniejszej niż n bez wprowadzenia dodatkowych zmiennych. Powiedzmy jednak, że jest to wynik czysto teoretyczny. (Po prostu dodaj kilka dodatkowych zmiennych ?! Z pewnością możesz to zrobić, aby zadowolić swojego szefa ...)

O wiele ważniejsze z punktu widzenia inżynierii oprogramowania jest najnowszy artykuł Erica S. Robertsa z 1995 r. Zatytułowany Loop Exits and Structured Programming: Reopening the Debate ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / LoopExits.pdf ). Roberts podsumowuje kilka badań empirycznych przeprowadzonych przez innych przed nim. Na przykład, gdy grupa studentów typu CS101 została poproszona o napisanie kodu dla funkcji realizującej wyszukiwanie sekwencyjne w tablicy, autor badania powiedział o tych studentach, którzy użyli break / return / goto do wyjścia z sekwencyjna pętla wyszukiwania, gdy element został znaleziony:

Nie znalazłem jeszcze ani jednej osoby, która spróbowała użyć programu przy użyciu [tego stylu], która stworzyła nieprawidłowe rozwiązanie.

Roberts mówi również, że:

Uczniowie, którzy próbowali rozwiązać problem bez wyraźnego powrotu z pętli for, radzili sobie znacznie gorzej: tylko siedmiu z 42 uczniów próbujących zastosować tę strategię udało się wypracować prawidłowe rozwiązania. Liczba ta stanowi wskaźnik sukcesu mniejszy niż 20%.

Tak, możesz być bardziej doświadczony niż studenci CS101, ale bez użycia instrukcji break (lub równoważnie return / goto ze środka pętli), w końcu napiszesz kod, który przy nominalnej ładnej strukturze jest wystarczająco włochaty pod względem dodatkowej logiki zmienne i powielanie kodu, że ktoś, prawdopodobnie ty, wprowadzi do niego błędy logiczne, starając się podążać za stylem twojego szefa.

Powiem też tutaj, że artykuł Roberta jest o wiele bardziej dostępny dla przeciętnego programisty, więc lepiej najpierw przeczytać niż Knutha. Jest także krótszy i obejmuje węższy temat. Prawdopodobnie mógłbyś nawet polecić to swojemu szefowi, nawet jeśli jest to kierownictwo, a nie typ CS.

Nie rozważam zastosowania żadnej z tych złych praktyk, ale użycie ich zbyt wiele w tej samej pętli powinno uzasadnić przemyślenie logiki używanej w tej pętli. Używaj ich oszczędnie.

Podany przykład nie wymaga przerw ani kontynuacji:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

Mój „problem” z 4 liniami w twoim przykładzie polega na tym, że wszystkie są na tym samym poziomie, ale robią różne rzeczy: niektóre przerwy, niektóre kontynuują ... Musisz przeczytać każdą linię.

W moim podejściu zagnieżdżonym, im głębiej idziesz, tym bardziej „użyteczny” staje się kod.

Ale jeśli głęboko w środku znajdziesz powód, aby zatrzymać pętlę (inny niż warunek podstawowy), skorzystaj z przerwy lub powrotu. Wolę to niż użycie dodatkowej flagi, która ma zostać przetestowana w stanie najwyższego poziomu. Przerwa / powrót jest bardziej bezpośrednia; lepiej określa intencję niż ustawienie kolejnej zmiennej.

„Zło” zależy od tego, jak z nich korzystasz. Zazwyczaj przerwy w konstrukcjach zapętlonych używam TYLKO wtedy, gdy pozwoli mi to zaoszczędzić cykle, których nie można zapisać przez refaktoryzację algorytmu. Na przykład przeglądanie kolekcji w poszukiwaniu elementu o wartości w określonej właściwości ustawionej na true. Jeśli wszystko, co musisz wiedzieć, to że jeden z elementów miał tę właściwość ustawioną na true, po osiągnięciu tego wyniku dobrze jest przerwać, aby odpowiednio zakończyć pętlę.

Jeśli użycie przerwy nie sprawi, że kod będzie łatwiejszy do odczytania, krótszy do uruchomienia lub zapisania cykli w przetwarzaniu w znaczący sposób, najlepiej ich nie używać. Zazwyczaj koduję do „najniższego wspólnego mianownika”, gdy jest to możliwe, aby upewnić się, że każdy, kto mnie śledzi, może z łatwością spojrzeć na mój kod i dowiedzieć się, co się dzieje (nie zawsze mi się to udaje). Przerwy zmniejszają to, ponieważ wprowadzają nieparzyste punkty wejścia / wyjścia. Nadużywane mogą zachowywać się bardzo podobnie jak nieudane oświadczenie „goto”.

Absolutnie nie ... Tak, użycie gotojest złe, ponieważ psuje strukturę twojego programu, a także bardzo trudno jest zrozumieć przepływ sterowania.

Ale korzystanie z takich stwierdzeń jest breaki continuejest absolutnie konieczne w dzisiejszych czasach i wcale nie jest uważane za złą praktykę programowania.

A także niezbyt trudne do zrozumienia przepływu kontroli w użyciu breaki continue. W konstrukcjach takich jak switchna breakrachunku jest to absolutnie konieczne.

Zasadnicze pojęcie wynika z możliwości semantycznej analizy programu. Jeśli masz jeden wpis i jedno wyjście, matematyka potrzebna do oznaczenia możliwych stanów jest znacznie łatwiejsza niż w przypadku zarządzania ścieżkami rozwidlenia.

Po części ta trudność odzwierciedla koncepcyjne uzasadnienie twojego kodu.

Szczerze mówiąc, twój drugi kod nie jest oczywisty. Co to robi? Czy kontynuuje „kontynuuj”, czy „kontynuuje” pętlę? Nie mam pojęcia. Przynajmniej twój pierwszy przykład jest jasny.

Zamieniłbym twój drugi fragment kodu na

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

nie z powodu zwięzłości - tak naprawdę uważam, że jest to łatwiejsze do odczytania i dla kogoś, kto rozumie, co się dzieje. Ogólnie rzecz biorąc, warunki dla twoich pętli powinny być zawarte wyłącznie w tych warunkach pętli, które nie są zaśmiecone w całym ciele. Jednak istnieją pewne sytuacje, w których breaki continuemogą pomóc czytelności. breakwięcej niż continuemógłbym dodać: D

Nie zgadzam się z twoim szefem. Są odpowiednie dla miejsc breaki continuema być używany. W rzeczywistości przyczyną wykonania i obsługi wyjątków we współczesnych językach programowania jest to, że nie można rozwiązać każdego problemu za pomocą just structured techniques.

Na marginesie nie chcę tutaj rozpoczynać dyskusji religijnej, ale możesz zmienić strukturę kodu, aby był jeszcze bardziej czytelny:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

Po drugiej stronie notatki

Osobiście nie podoba mi się stosowanie ( flag == true )warunkowe, ponieważ jeśli zmienna jest już wartością logiczną, to wprowadzasz dodatkowe porównanie, które musi się zdarzyć, gdy wartość logiczna ma odpowiedź, której chcesz - chyba że jesteś pewien, że twój kompilator zoptymalizuj to dodatkowe porównanie.

Zgadzam się z twoim szefem. Są złe, ponieważ wytwarzają metody o dużej złożoności cyklomatycznej. Takie metody są trudne do odczytania i trudne do przetestowania. Na szczęście istnieje łatwe rozwiązanie. Wyodrębnij treść pętli do osobnej metody, w której „kontynuacja” staje się „powrotem”. „Powrót” jest lepszy, ponieważ po „powrocie” to koniec - nie ma obaw o stan lokalny.

Aby „przerwać”, wypakuj samą pętlę do osobnej metody, zastępując „przerwanie” słowem „powrót”.

Jeśli wyodrębnione metody wymagają dużej liczby argumentów, jest to wskazanie do wyodrębnienia klasy - albo zbierz je do obiektu kontekstu.

Myślę, że to problem tylko wtedy, gdy jest głęboko osadzony w wielu pętlach. Trudno wiedzieć, do której pętli się zrywasz. Kontynuacja może być również trudna, ale myślę, że prawdziwy ból pochodzi z przerw - logika może być trudna do naśladowania.

O ile nie są używane jako ukryte goto, jak w poniższym przykładzie:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

Nic mi nie jest. (Przykład widoczny w kodzie produkcyjnym, meh)

Nie lubię żadnego z tych stylów. Oto co wolałbym:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

Naprawdę nie lubię używać returndo przerywania funkcji. To jest jak nadużyciereturn .

Za pomocą break również nie zawsze jest czytelne.

Jeszcze lepiej może być:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

mniej zagnieżdżania, a złożone warunki są przekształcane w zmienne (w prawdziwym programie trzeba by mieć lepsze nazwy, oczywiście ...)

(Cały powyższy kod jest pseudokodem)

Nie. To sposób na rozwiązanie problemu i istnieją inne sposoby jego rozwiązania.

Wiele obecnych języków głównego nurtu (Java, .NET (C # + VB), PHP, pisz własne) używa „break” i „kontynuuj”, aby pominąć pętle. Oba zdania „ustrukturyzowane goto (s)”.

Bez nich:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

Z nimi:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

Zauważ, że kod „przerwa” i „kontynuuj” jest krótszy i zwykle zamienia „a” w „zdania” na „for” lub „foreach”.

Oba przypadki są kwestią stylu kodowania. Wolę ich nie używać , ponieważ pełny styl pozwala mi mieć większą kontrolę nad kodem.

Właściwie pracuję w niektórych projektach, w których użycie tych zdań było obowiązkowe.

Niektórzy programiści mogą myśleć, że nie są to konieczne, ale hipotetyczne, gdybyśmy musieli je usunąć, musielibyśmy usunąć „while” i „do while” („powtarzaj do”, chłopaki pascal) ;-)

Wniosek, nawet jeśli wolę ich nie używać, uważam, że jest to opcja, a nie zła praktyka programistyczna.

Nie jestem przeciwko continueibreak zasady, ale myślę, że są one bardzo niskiego poziomu konstruktów, które bardzo często mogą być zastąpione przez coś jeszcze lepszego.

Używam C # jako przykładu, rozważmy przypadek iteracji nad kolekcją, ale chcemy tylko elementów spełniających pewne predykaty i nie chcemy robić więcej niż maksymalnie 100 iteracji.

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

Wygląda to POWAŻNIE czysto. Nie jest to trudne do zrozumienia. Sądzę jednak, że wiele zyskałoby na byciu bardziej deklaratywnym. Porównaj to z następującymi:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

Może połączenia Gdzie i Odbierz nie powinny nawet być w tej metodzie. Może to filtrowanie należy wykonać PRZED przekazaniem kolekcji do tej metody. W każdym razie, odchodząc od niskiego poziomu i skupiając się bardziej na rzeczywistej logice biznesowej, staje się bardziej jasne, czym faktycznie jesteśmy zainteresowani. Łatwiej jest podzielić nasz kod na spójne moduły, które bardziej odpowiadają dobrym praktykom projektowym i tak dalej na.

Niski poziom nadal będzie istniał w niektórych częściach kodu, ale chcemy to ukryć tak bardzo, jak to możliwe, ponieważ wymaga to energii mentalnej, którą moglibyśmy wykorzystać do uzasadnienia problemów biznesowych.

Code Complete ma fajną sekcję na temat używaniagoto i wielokrotnych zwrotów z procedury lub pętli.

Ogólnie rzecz biorąc, nie jest to zła praktyka. breaklub continuepowiedz dokładnie, co będzie dalej. I zgadzam się z tym.

Steve McConnell (autor Code Complete) używa prawie takich samych przykładów, jak ty, aby pokazać zalety używania różnych gotoinstrukcji.

Jednak nadużywanie breaklub continuemoże prowadzić do złożonego i niemożliwego do utrzymania oprogramowania.