Czy while (prawda) z break jest złą praktyką programistyczną?

Cytując tego znanego twórcę days gone by, Wordswortha:

...
W prawdzie Więzienie, do którego skazujemy
Nas samych, żadne więzienie nie jest; i stąd dla mnie,
W różnych nastrojach, ' twas hobby to be bound
W obrębie sonetu skąpy wątek ziemi;
Zadowolony, jeśli niektóre dusze (dla takich ich potrzeb muszą być)
Którzy poczuli ciężar zbyt wielkiej wolności,
Powinienem znaleźć tam krótką pociechę, tak jak ja znalazłem.

Zgadzam się, że czasami wczesne wyjście jest najprostszym sposobem wyrażenia działania. Jednak moje doświadczenie było takie, że kiedy zmuszam się do korzystania z najprostszych możliwych struktur sterowania (i naprawdę myślę o projektowaniu w ramach tych ograniczeń), najczęściej stwierdzam, że rezultatem jest prostszy, jaśniejszy kod. Wada z

while (true) {
    action0;
    if (test0) break;
    action1;
}

Jest to, że łatwo jest pozwolić action0 i action1 stać się coraz większymi kawałkami kodu, lub dodać" jeszcze jedną " sekwencję test-break-action, aż trudno będzie wskazać konkretną linię I odpowiedzieć na pytanie :" jakie warunki mam znać w tym momencie?"Tak więc, nie ustalając reguł dla innych programistów, staram się unikać idiomu while (true) {...} w moim własnym kodzie o ile to możliwe.

Kiedy możesz napisać swój kod w formularzu

while (condition) { ... }

Lub

while (!condition) { ... }

Z brak wyjść (break, continue, lub goto) w ciele, ta forma jest preferowana, ponieważ ktoś może odczytać kod i zrozumieć warunek zakończenia po prostu patrząc na nagłówek . To dobrze.

Ale wiele pętli nie pasuje do tego modelu, a nieskończona pętla z wyraźnym wyjściem(s) w środku jest honorowym modelem. (Pętle z continue są zwykle trudniejsze do understand than loops with break.) Jeśli chcesz mieć jakieś dowody lub autorytet do cytowania, nie szukaj dalej niż słynny artykuł Dona Knutha na temat strukturalnego programowania ze stwierdzeniami Goto ; znajdziesz tutaj wszystkie przykłady, argumenty i wyjaśnienia, które możesz chcieć.

Drobny punkt idiomu: pisanie while (true) { ... } określa cię jako starego programistę Pascala lub być może w dzisiejszych czasach programistę Javy. Jeśli piszesz W C lub c++, preferowanym idiomem jest

for (;;) { ... }

There ' s no good powód tego, ale powinieneś napisać to w ten sposób, ponieważ programiści C oczekują, że to zobaczą.

Wolę

while(!<some condition>) {
    //do something
}

Ale myślę, że to bardziej kwestia czytelności, a nie możliwości " zapomnienia przerwy."Myślę, że zapomnienie break jest raczej słabym argumentem, ponieważ byłby to błąd i od razu go Znajdziesz i naprawisz.

Argumentem przeciwko używaniu break, aby wydostać się z niekończącej się pętli jest to, że zasadniczo używasz break jako goto. Nie jestem religijnie przeciwny używaniu goto (jeśli język go obsługuje, to jest to uczciwa gra), ale ja spróbuj go zastąpić, jeśli istnieje bardziej czytelna alternatywa.

W przypadku wielu break punktów zamieniłbym je na

while( !<some condition> ||
       !<some other condition> ||
       !<something completely different> ) {
    //do something
}

Konsolidacja wszystkich warunków zatrzymania w ten sposób znacznie ułatwia zobaczenie, co zakończy tę pętlę. break wypowiedzi mogą być posypane, a to wszystko, ale nie jest czytelne.

While (true) może mieć sens, jeśli masz wiele stwierdzeń i chcesz się zatrzymać, jeśli jakieś zawiodą

 while (true) {
     if (!function1() ) return;   
     if (!function2() ) return;   
     if (!function3() ) return;   
     if (!function4() ) return;  
   }

Jest lepszy niż

 while (!fail) {
     if (!fail) {
       fail = function1()
     }           
     if (!fail) {
       fail = function2()
     }  
     ........

   }

Javier zrobił ciekawy komentarz do mojej wcześniejszej odpowiedzi (tej cytującej Wordswortha):

Myślę, że while (true){} jest bardziej' czystą ' konstrukcją niż while (condition){}.

I nie mogłem odpowiedzieć adekwatnie w 300 znaków (sorry!)

W moim nauczaniu i mentoringu nieformalnie zdefiniowałem " złożoność "jako" ile reszty kodu muszę mieć w głowie, aby móc zrozumieć tę pojedynczą linijkę lub wyrażenie?"The more stuff I have to pamiętaj, że im bardziej skomplikowany jest kod. Im więcej Kod mówi mi wyraźnie, tym mniej złożony.

Myślę o tym fragmencie kodu:

while (c1) {
    // p1
    a1;
    // p2
    ...
    // pz
    az;
}

Jako wyrażanie dwóch rzeczy jednocześnie:

1. (całe) ciało będzie powtarzane tak długo, jak c1 pozostanie prawdziwe i
2. w punkcie 1, Gdzie a1 jest wykonywana, c1 jest gwarantowane trzymać.

Różnica polega na perspektywie; pierwsza z nich ma do czynienia z zewnętrznym, dynamicznym zachowaniem całej pętli w ogóle, podczas gdy druga jest przydatna do zrozumienia wewnętrznej, statycznej gwarancji, na którą mogę liczyć, myśląc o a1 w szczególności. Oczywiście efekt netto a1 może unieważnić c1, wymagając, żebym się bardziej zastanowił nad tym, na co mogę liczyć w punkcie 2 itp.

Dajmy konkretny (malutki) przykład w miejsce do zastanowienia się nad stanem i pierwszą czynnością:

while (index < length(someString)) {
    // p1
    char c = someString.charAt(index++);
    // p2
    ...
}

"zewnętrzny" problem polega na tym, że pętla wyraźnie robi coś wewnątrz someString, co może być zrobione tylko tak długo, jak index jest umieszczony w someString. To ustawia oczekiwanie, że będziemy modyfikować index lub someString wewnątrz ciała (w miejscu i sposobie Nie znanym, dopóki nie zbadam ciała), tak aby ostatecznie nastąpiło zakończenie. Daje mi to zarówno kontekst, jak i oczekiwanie na myślenie o ciele.

The "wewnętrzny" problem polega na tym, że mamy gwarancję, że działanie po punkcie 1 będzie legalne, więc czytając kod w punkcie 2 mogę myśleć o tym, co jest robione z wartością znaku i wiem, że zostało legalnie uzyskane. (Nie możemy nawet ocenić warunku, jeśli someString jest NULL ref, ale zakładam również, że zabezpieczyliśmy się przed tym w kontekście wokół tego przykładu!)

Natomiast pętla postaci:

while (true) {
    // p1
    a1;
    // p2
    ...
}

Zawodzi mnie w obu kwestiach. / Align = "left" / zastanawiając się, czy oznacza to, że I naprawdę powinien oczekiwać, że ta pętla będzie się obracać w nieskończoność (np. główna pętla dyspozytorska systemu operacyjnego), czy też dzieje się coś innego. Nie daje mi to ani wyraźnego kontekstu czytania ciała, ani oczekiwania co do tego, co stanowi postęp w kierunku (niepewnego) zakończenia.

Na poziomie wewnętrznym, nie mam absolutnie żadnej wyraźnej gwarancji o wszelkich okolicznościach, które mogą mieć miejsce w punkcie 1. Warunek true, co jest oczywiście prawdą wszędzie, jest najsłabszym możliwym stwierdzeniem na temat tego, co możemy wiedzieć w dowolnym momencie programu. Zrozumienie warunków wstępnych działania jest bardzo cenną informacją podczas próby myślenia o tym, co działanie osiąga!

Sugeruję więc, że idiom while (true) ... jest znacznie bardziej niekompletny i słaby, a zatem bardziej złożony, niż while (c1) ... zgodnie z logiką, którą opisałem powyżej.

Pierwszy jest OK, jeśli istnieje wiele sposobów przerwania pętli lub jeśli warunek przerwania nie może być łatwo wyrażony w górnej części pętli (na przykład zawartość pętli musi być uruchomiona w połowie, ale druga połowa nie może być uruchomiona podczas ostatniej iteracji).

Ale jeśli możesz tego uniknąć, powinieneś, ponieważ programowanie powinno polegać na pisaniu bardzo złożonych rzeczy w najbardziej oczywisty możliwy sposób, przy jednoczesnym prawidłowym i wydajnym wdrażaniu funkcji. Dlatego twój przyjaciel jest w ogólna sprawa, zgadza się. Sposób pisania konstrukcji pętli Twojego znajomego jest o wiele bardziej oczywisty(zakładając, że warunki opisane w poprzednim akapicie nie uzyskają).

Czasami potrzebujesz nieskończonej pętli, na przykład nasłuchiwania na porcie lub oczekiwania na połączenie.

Więc while (true)... nie powinien być klasyfikowany jako dobry lub zły, niech sytuacja zdecyduje, czego użyć

To zależy od tego, co próbujesz zrobić, ale ogólnie wolę umieścić warunkowe w czasie.

• to prostsze, ponieważ nie potrzebujesz kolejnego testu w kodzie.
• jest łatwiejszy do odczytania, ponieważ nie musisz polować na przerwę w pętli.
Odkrywasz koło na nowo. Cały sens while jest zrobić coś tak długo, jak test jest prawdą. Po co to podważać, stawiając warunek przerwania gdzieś indziej?

I ' d use a while (true) pętla, jeśli pisałem demona lub inny proces, który powinien działać, dopóki nie zostanie zabity.

Jeśli istnieje jeden (i tylko jeden) nie-wyjątkowy warunek przerwania, umieszczenie tego warunku bezpośrednio w konstrukcji sterowania przepływem (while) jest lepsze. Seeing while (true) { ... } sprawia, że jako czytacz kodu myślę, że nie ma prostego sposobu, aby wyliczyć warunki przerwy i sprawia, że myślę " przyjrzyj się uważnie temu i zastanów się uważnie nad warunkami przerwy (co jest ustawione przed nimi w pętli bieżącej i co mogło być ustawione w poprzedniej pętli)"

W skrócie, Jestem z twoim kolegą w najprostszym przypadku, ale podczas (true) {... nie jest rzadkością .

Odpowiedź doskonałego konsultanta: to zależy. W większości przypadków właściwą rzeczą jest użycie pętli while

while (condition is true ) {
    // do something
}

Lub "repeat until", który jest wykonywany w języku C z

do {
    // do something
} while ( condition is true);

Jeśli któryś z tych przypadków działa, użyj ich.

Czasami, jak w wewnętrznej pętli serwera, masz na myśli, że program powinien działać, dopóki coś zewnętrznego go nie przerywa. (Rozważ np. demona httpd - nie zatrzyma się chyba, że się zawiesi lub zostanie zatrzymany przez wyłączenie.)

wtedy i tylko wtedy użyj while (1):

while(1) {
   accept connection
   fork child process
}

Ostatni przypadek jest rzadką okazją, w której chcesz wykonać jakąś część funkcji przed zakończeniem. W takim przypadku należy użyć:

while(1) { // or for(;;)
   // do some stuff
   if (condition met) break;
   // otherwise do more stuff.
}

Jest już zasadniczo identyczne pytanie, więc na jest WHILE TRUE ... BREAK ... END WHILE a good design?. @ Glomek odpowiedział (A):

Czasami jest to bardzo dobry projekt. Zobacz Structured Programming With Goto Statements autorstwa Donalda Knutha. Używam tej podstawowej idei często dla pętli, które działają "n i pół razy", zwłaszcza pętli read / process. Jednak generalnie staram się mieć tylko jedno stwierdzenie przerwy. Ułatwia to powód o stanie programu po zakończeniu pętli.

Nieco później odpowiedziałem pokrewnym, a także żałośnie niedocenianym, komentarzem (po części dlatego, że nie zauważyłem Glomka za pierwszym razem, chyba):

[1]}jednym z fascynujących artykułów jest "Structured Programming with go to Statements" Knutha z 1974 roku (dostępny w jego książce "literate Programming" i prawdopodobnie również gdzie indziej). Omawia m.in. kontrolowane sposoby wyłamywania się z pętli, oraz (nie używając terminu) wyrażenie loop-and-a-half.

Ada zapewnia również konstrukcje pętlowe, w tym

loopname:
    loop
        ...
        exit loopname when ...condition...;
        ...
    end loop loopname;

Oryginalny kod pytania jest podobny do tego w intencji.

Jedną z różnic pomiędzy opisywanym elementem SO a tym jest 'FINAL break'; jest to pętla z pojedynczym strzałem, która używa break do wcześniejszego wyjścia z pętli. Pojawiły się pytania, czy to też dobry styl - nie mam pod ręką odsyłacza.

Nie, to nie jest złe, ponieważ może nie zawsze znać warunek wyjścia podczas konfigurowania pętli lub może mieć wiele warunków wyjścia. Jednak wymaga to większej ostrożności, aby zapobiec nieskończonej pętli.

To nie tyle while(true) część, która jest zła, ale fakt, że musisz się z niej wyłamać lub wydostać, jest problemem. break i goto nie są tak naprawdę akceptowalnymi metodami kontroli przepływu.

Ja też nie widzę sensu. Nawet w czymś, co zapętla się przez cały czas trwania programu, możesz przynajmniej mieć coś w rodzaju logiki o nazwie Quit lub coś, co ustawisz na true, aby poprawnie wyjść z pętli w pętli takiej jak while(!Quit)... Nie tylko wywołanie przerwy w jakimś arbitralnym momencie i wyskakując,

Problem polega na tym, że nie każdy algorytm trzyma się modelu " while (cond) {action}".

Ogólny model pętli wygląda następująco:

loop_prepare
 loop:
  action_A
  if(cond) exit_loop
  action_B
  goto loop
after_loop_code

Gdy nie ma action_A można go zastąpić przez:

loop_prepare
  while(cond)
  action_B
after_loop_code

Gdy nie ma action_B można go zastąpić przez:

loop_prepare
  do action_A
  while(cond)
after_loop_code

W ogólnym przypadku, action_A będzie wykonywane n razy, a action_B (n-1) razy.

Prawdziwym przykładem jest: wypisanie wszystkich elementów tabeli oddzielonych przecinkami. Chcemy wszystkich N elementów z (N-1) przecinkami.

Zawsze możesz zrobić kilka sztuczek, aby trzymać się modelu pętli while, ale to zawsze powtórzy kod lub sprawdzi dwa razy ten sam warunek (dla każdej pętli) lub doda nową zmienną. Więc zawsze będziesz mniej wydajny i mniej czytelny niż model pętli while-true-break.

Przykład (bad) "trick": dodaj zmienną i warunek

loop_prepare
b=true // one more local variable : more complex code
 while(b): // one more condition on every loop : less efficient
  action_A
  if(cond) b=false // the real condition is here
  else action_B
after_loop_code

Przykład (złego) "tricku": powtórz kod. Powtarzającego się kodu nie wolno zapominać podczas modyfikowania jednego z dwie sekcje.

loop_prepare
action_A
 while(cond):
  action_B
  action_A
after_loop_code

Uwaga: w ostatnim przykładzie programista może zaciemnić (dobrowolnie lub nie) kod, mieszając "loop_prepare" z pierwszym "action_A", a action_B z drugim action_A. więc może mieć wrażenie, że tego nie robi.

Prawdopodobnie ma rację.

Funkcjonalnie oba mogą być identyczne.

Jednak dla czytelności i zrozumienia przepływu programu while (warunek) jest lepszy. Przerwa uderza bardziej w goto. While (warunek) jest bardzo jasne na warunkach, które kontynuują pętlę, itd. To nie znaczy, że break jest zły, po prostu może być mniej czytelny.

Kilka zalet korzystania z tej drugiej konstrukcji, które przychodzą mi do głowy:

• Łatwiej jest zrozumieć, co robi pętla bez szukania przerw w kodzie pętli.

• Jeśli nie używasz innych przerw w kodzie pętli, w pętli jest tylko jeden punkt wyjścia i jest to warunek while ().

• Generalnie kończy się mniej kodu, co zwiększa czytelność.

Wolę chwilę(!) podejść, ponieważ wyraźniej i natychmiast przekazuje intencję pętli.

Wiele mówi się tutaj o czytelności i jej bardzo dobrze skonstruowanej, ale jak w przypadku wszystkich pętli, które nie są ustalone w rozmiarze(tj. do while I while) biegasz na ryzyko.

His reasoning was that you could "forget the break" too easily and have an endless loop.

W pętli while W rzeczywistości prosisz o proces, który trwa w nieskończoność, chyba że coś się wydarzy, a jeśli to coś nie wydarzy się w określonym parametrze, otrzymasz dokładnie to, czego chciałeś... nieskończona pętla.

Myślę, że zaletą użycia "while(true)" jest prawdopodobnie umożliwienie napisania wielu warunków wyjścia, szczególnie jeśli te warunki wyjścia muszą pojawić się w innym miejscu w bloku kodu. Jednak dla mnie może to być chaotyczne, gdy muszę wyschnąć kod, aby zobaczyć, jak kod wchodzi w interakcje.

Osobiście postaram się unikać while (true). Powodem jest to, że za każdym razem, gdy patrzę wstecz na kod napisany wcześniej, zwykle stwierdzam, że muszę dowiedzieć się, kiedy działa/kończy bardziej niż to, co robi. Dlatego konieczność zlokalizowania "przerw" w pierwszej kolejności jest dla mnie nieco kłopotliwa.

Jeśli istnieje potrzeba wielokrotnego warunku wyjścia, mam tendencję do refaktoryzacji warunku określającego logikę w oddzielną funkcję, aby blok pętli wyglądał na czysty i łatwiejszy do zrozumienia.

To, co poleca twój przyjaciel, różni się od tego, co zrobiłeś. Twój własny kod jest bardziej podobny do

do{
    // do something
}while(!<some condition>);

Które zawsze uruchamiają pętlę przynajmniej raz, niezależnie od warunku.

while(true){
    // do something
if(<some condition>) break;
    // continue do something
}

Przez dobre wcięcie, punkt przerwania jest jasny dla pierwszego czytelnika kodu, wygląda tak strukturalnie, jak kody, które Przerwa na początku lub na dole pętli.

Używanie pętli typu

While (1) {do stuff }

Jest konieczne w niektórych sytuacjach. Jeśli wykonasz programowanie systemów wbudowanych (pomyśl o mikrokontrolerach, takich jak PICs, MSP430 i programowanie DSP), prawie cały Twój kod będzie za chwilę(1) zapętlony. Podczas kodowania dla DSP czasami wystarczy trochę czasu(1) {}, a reszta kodu to procedura obsługi przerwań (ISR).

Bardziej lubię for pętle:

for (;;)
{
    ...
}

Lub nawet

for (init();;)
{
    ...
}

Ale jeśli init() funkcja wygląda jak ciało pętli, lepiej z

do
{
    ...
} while(condition);