Co tam panie z tym break'iem?

[Korialtrash]

W ostatniej klasie liceum zmienił się nauczyciel informatyki. Odetchnąłem z ulgą, bo zamiast robić formatowanie w Wordzie, od pierwszej lekcji zaczęła się ostra jazda (topologie sieci, itp.), zahaczając nawet o takie rzeczy jak implementacja algorytmów genetycznych (!)
No, ale do rzeczy:
siedzę przed komputerem i klepię w Dev-CPP (bo VisualExpressa nie pozwalają nam zainstalować). Pani profesor zagląda mi przez ramię.
 - Piotrek, dlaczego używasz break'ów w pętli?
Popatrzyłem się zaskoczony. Prof. słynie z tego, że podpuszcza uczniów więc ostrożnie zapytałem:
 - Co innego mógłbym zrobić?
 - Inaczej skonstruować warunek w while'u.
To mnie zastanowiło, ale postanowiłem zabrnąć dalej:
 - Dlaczego miałbym tego nie używać?
 - A dlaczego nie używasz etykiet?
 - Bo to nieprofesjonalne.
 - Tak jak i break'i.
Tutaj pani profesor odeszła, zostawiając mnie osłupiałego. W chwilę później zadzwonił dzwonek i nie wróciłem już do tego tematu, ale ostatnio zaczęło mnie to prześladować:

czy break w pętli jest równie niewskazany jak etykieta?

Zastanowiła mnie jeszcze jedna rzecz:
dlaczego niektórzy piszą for( ; ; ) zamiast while(true)?

[Gravell]

Zastanowiła mnie jeszcze jedna rzecz:
dlaczego niektórzy piszą for( ; ; ) zamiast while(true)?

Bo gdy się chce zrobić coś określona ilość razy pisze się pętlę for,a gdy nie wie się ile razy ma się ona wykonać to jakoś tak odruchowo zmienia się na for( ; ; ). Przynajmniej ja tak mam .

A co do breaków - wg mnie są one na pewno dużo bardziej wskazane niż etykiety. W ogóle pierwszy raz spotykam się z pojęciem "niewskazanego break'a".

Pozdro .

[counterClockWise]

- A dlaczego nie używasz etykiet?
 - Bo to nieprofesjonalne.
 - Tak jak i break'i.
Tutaj pani profesor odeszła, zostawiając mnie osłupiałego. W chwilę później zadzwonił dzwonek i nie wróciłem już do tego tematu, ale ostatnio zaczęło mnie to prześladować:

czy break w pętli jest równie niewskazany jak etykieta?

Moim zdaniem to nauczycielka się czepia, bo taką ma pracę albo jest zła, że nie klepię komercyjnych programów tylko uczy w szkolę (chociaż wątpię w to, że poświęca się tylko nauczaniu).

Ja tam używam breaków w pętli, (może jestem nieprofesjonalny ) i nie widzę w tym nic złego.
W ogóle to niech ktoś poda właściwsze miejsce dla break'a od pętli Przecież został wymyślony, aby wychodzić z bloków switch lub pętli.

[therealremi]

Podejrzewam ze post Gravella jest jednoczesnie odpowiedzia na to pytanie: prawdopodobnie break nie byl potrzebny w tym przypadku - bardziej czytelne byloby inne skonstruowanie warunku while. Czytelniejsze jest miec wszystkie warunki wyjscia w jednym miejscu niz stado if-ow i break-ow w roznych miejscach.

[Anton Chigurh]

Breaków należy unikać jeśli tylko się da, a w wielu przypadkach tak właśnie jest. Jednak chyba jedyną przemawiającą za tym przesłanką jest czytelność kodu. Warto się 3 razy zastanowić przed wstawieniem break'a, ale ja bym nie przesadzał. Jeśli chodzi o etykiety, to one robią bigos we flow-ie programu i są do szpiku kości ZŁE, chyba, że konstruuje się asm-o / BASIC-o podobny kod i w ogóle nie używa zwykłych konstrukcji, ale wtedy użycie c++/javy/c# podchodzi pod pomyłkę.

co do pętli while(true) imo też są dość nieeleganckie i też rczej bym ich unikał. Znów - w bardzo wielu przypadkach da się tego uniknąć no i patrząc na kod - od razu wiesz, kiedy wyskakujesz z pętli, zamiast szukać nie wiadomo gdzie i nie wiadomo ilu breaków. Ale też i tutaj nie należy przesadzać i kierować isę zdrowym rozsądkiem.

Innymi słowy jeśli używasz pętli to powinieneś robić t zgodnie z jej zastosowaniem. W innym przypadku możesz skończyć w sytuacji analogicznej do mieszania kleju do glazury przy pomocy śrubokrętu.

Są też kontrowersyjne zastosowania pętli, nieistniejące bez break'ów, takie jak np. "do-while-false", ale ich "czystość" czy "słuszność" uważam za bardzo dyskusyjną.

PS. mnie kiedyś w liceum pani skrzyczała za "repeat (...) until (3 = 1)". Ale przy ograniczeniu do 45 lub 90 minut oczekiwanie od kogoś czystego kodu jest nonsensem również sprzecznym z niejedną regułą programowania.

[counterClockWise]

Breaków należy unikać jeśli tylko się da, a w wielu przypadkach tak właśnie jest. Jednak chyba jedyną przemawiającą za tym przesłanką jest czytelność kodu. Warto się 3 razy zastanowić przed wstawieniem break'a, ale ja bym nie przesadzał. Jeśli chodzi o etykiety, to one robią bigos we flow-ie programu i są do szpiku kości ZŁE, chyba, że konstruuje się asm-o / BASIC-o podobny kod i w ogóle nie używa zwykłych konstrukcji, ale wtedy użycie c++/javy/c# podchodzi pod pomyłkę.

co do pętli while(true) imo też są dość nieeleganckie i też rczej bym ich unikał. Znów - w bardzo wielu przypadkach da się tego uniknąć no i patrząc na kod - od razu wiesz, kiedy wyskakujesz z pętli, zamiast szukać nie wiadomo gdzie i nie wiadomo ilu breaków. Ale też i tutaj nie należy przesadzać i kierować isę zdrowym rozsądkiem.

Innymi słowy jeśli używasz pętli to powinieneś robić t zgodnie z jej zastosowaniem. W innym przypadku możesz skończyć w sytuacji analogicznej do mieszania kleju do glazury przy pomocy śrubokrętu.

Są też kontrowersyjne zastosowania pętli, nieistniejące bez break'ów, takie jak np. "do-while-false", ale ich "czystość" czy "słuszność" uważam za bardzo dyskusyjną.

PS. mnie kiedyś w liceum pani skrzyczała za "repeat (...) until (3 = 1)". Ale przy ograniczeniu do 45 lub 90 minut oczekiwanie od kogoś czystego kodu jest nonsensem również sprzecznym z niejedną regułą programowania.

Dlaczego uważasz, że breaków należy unikać kiedy tylko się da?
Nie zapędzajmy się daleko - bo zawsze da się uniknać - zawsze można obudować funkcjonalność pętli w funkcję i zwracać cały interesujący nas stan zamiast przerywać break'iem.

A moim zdaniem breaków się powinno unikać tylko jeśli jesteśmy w stanie wyznaczyć ile razy ma się wykonać pętla - wtedy break to bład, owszem.
No i w przypadku nieskończonych pętli też jest brzydki (bo nieskończone pętle same w sobie ładne nie są - są trochę błędogenne nienaturalne, nie wynikają z żadnego problemu z natury), ale gdy przeszukujemy liniowo jakąś tablicę po pierwszy element spełniający zadane kryterium, a następnie chcemy coś dalej z tym elementem robić to czemu nie?

[Elwis]

Coś słyszałem o krytyce pod adresem instrukcji break, ale myślę, że o ile goto rzeczywiście psuje czytelność, to break w niczym nie przeszkadza. Tak trudno znaleźć koniec pętli?

[counterClockWise]

Coś słyszałem o krytyce pod adresem instrukcji break, ale myślę, że o ile goto rzeczywiście psuje czytelność, to break w niczym nie przeszkadza. Tak trudno znaleźć koniec pętli?

Masz dynamiczną liniową strukturę danych bez żadnego posortowania i szukasz jakiegoś elementu. Następnie chcesz coś z tym elementem dalej robić w tej samej funkcji - bez 'break' masz zawsze złożoność pesymistyczną, a tak sobie przerwiesz szukanie.

[infernus]

Mnie NIGDY nie zadarzylo sie uzyc break. Wcale jednak nie uwazam ze sa one zle i ze nalezy sie ich wystrzegac czasem ich uzycie moze okazac sie koniecznoscia (jak i czasem konieczne moze byc wykorzystanie goto). W konstrukcji switch na przyklad sa one jedynym sensownym sposobem sterowanie jej przebiegiem.

[Kos]

Kod imo jest dobry tak długo jak jest (a) w miarę optymalny (na tyle, na ile potrzeba) i (b) czytelny (j.w.). Break lub continue w pętli często pozwala zachować 'logiczniejszą' strukturę. I o ile prawdą jest, że każde użycie breaka można zastąpić odpowiednią "ifologią", to nasuwa się pytanie - po co sobie komplikować kod i marnować pamięć na zmienne pomocnicze? To samo tyczy się goto - są nieliczne sytuacje, gdy tego używam, np. dla "podwójnego" breaka z zagnieżdżonej pętli. Kod jest przez to prostszy i - co ważne - przejrzysty i sensowny. O to chyba chodzi, prawda?

A jeśli taki nauczyciel usłyszał że "goto, jak również breaki, mogą sprawić że kod będzie przypominał spaghetti", to bardzo dobrze usłyszał, bo jak najbardziej mogą. Ale:
* Po pierwsze, odpowiednie i stosowne użycie tychże konstrukcji z kodu nam labiryryntu nie zrobi,
* Po drugie, dorabianie skomplikowanych warunków, zmiennych pomocniczych, może kod zaplątać (i spowolnić) równie łatwo co wspomniane wyżej instrukcje,
* Po trzecie, wyklinanie goto i breaków wszędzie, gdzie tylko się je zobaczy, bo "mądra wieść ludowa mówi że są złe" to w moim mniemaniu zwyczajny fanatyzm.

[counterClockWise]

Nie porównujmy 'goto' do 'break'

Ta pierwsza instrukcja zmienia sterowanie w sposób dosyć drastyczny i często niemożliwym jest domyślić się idei użycia osobie czytającej program (np. innemu programiście w tym samym projekcie). Takie dowolne skoki są bardzo błędogenne i zostawiłbym je tylko do niskopoziomowych zadań - tam 'goto' jak najbardziej.

Natomiast break zmienia sterowanie w sposób całkiem 'gładki' i przewidywalny. Dla mnie ciężko to porównywać.

[Gravell]

Mnie NIGDY nie zadarzylo sie uzyc break.

Hehe, nie wiesz co tracisz .

Co do porównywania break'a do etykiety to wg mnie jak porównywanie samochodu do telewizora. Etykiety to wynalazek z czasów gdy nie stosowano jeszcze OOP i był to świetny sposób na przeniesienie się z jednego miejsca kodu w inne*. Break to zwyczajna instrukcja do wyjścia z pętli. Dla przykładu przytoczę Symfonię C++: o ile o etykietach nie mówiło się tam w ogóle, lub wspomniało tylko na tyle bo powiedzieć "co to", ale nie zachęcać do używania, o tyle break został tam normalnie opisany i używany praktycznie "wszędzie gdzie się da". To chyba o czymś świadczy .

* Nie bijcie jeśli się mylę .

Pozdro

[yarpen]

Jak na liceum to bardzo ciekawe, bo to zalecenie rodem ze standardow programowania dla duzych firm . Pani profesor wie, co mowi. Niepotrzebny break w petli zwieksza zlozonosc cyklomatyczna f-kcji. Zobacz tez na przyklad "A Critical View of C++ Practices" Henneya - http://www.accu-usa.org/Slides/ACriticalViewOfCppPractices.pdf (Jumpy Code, strona 42 i dalsze)

[Krzysiek K.]

Cała sprawa z breakami wyszła z ideologii kodowania strukturalnego (każdy blok kodu ma jedno wejście i jedno wyjście), a breaki sa takim wyjściem "w bok". O ile z wadami goto się zgodze, to z breakami sprawa ma się tak, jak Kos napisał. Jednak cała walka narodów z niestrukturalnością spaliła na panewce po tym, jak ktoś wymyślił wyjątki, które są ekstremalnie niestrukturalne i po cichu mogą z controll flow'a zrobić jeszcze większe spaghetti niz nawet najbardziej perfidnie umieszczony break.

[Kos]

Nie porównujmy 'goto' do 'break'

Ta pierwsza instrukcja zmienia sterowanie w sposób dosyć drastyczny i często niemożliwym jest domyślić się idei użycia osobie czytającej program (np. innemu programiście w tym samym projekcie). Takie dowolne skoki są bardzo błędogenne i zostawiłbym je tylko do niskopoziomowych zadań - tam 'goto' jak najbardziej.

Natomiast break zmienia sterowanie w sposób całkiem 'gładki' i przewidywalny. Dla mnie ciężko to porównywać.

Break to przecież szczególny przypadek goto, tylko ciut bardziej sprecyzowany.

Kod:

while(warunek)
{
    jakas_funcja();
    while(inny_warunek)
    {
        inna_funkcja();
        if (warunek_wyjscia)
            goto koniecPetli;
    }
}
koniecPetli: /* ... */

Widzisz tu coś nieczytelnego lub nielogicznego? Niektóre języki (Visual Basic PHP) obsługują coś takiego bez labeli, na podobnej zasadzie jak "zwykły" break w C, lecz jedną instrukcją pozwalają na wyjście z dowolnej ilości zagnieżdżonych pętli. W C jest jedynie pojedynczy break, dlatego takie użycie goto czasami bywa wygodne.