Przemierzałem sobie bezkresne obszary http://www.gamedev.net i natrafiłem tam na fajny mechanizm o nazwie DWF. Wygląda to tak:
do {
if( !doSth() ) break;
if( !doSthElse() ) break;
if( !doAnotherThing() ) break;
doLastThing();
} while( false );
Na pierwszy rzut oka mechanizm bez sensu. Po co pętla skoro i tak wiadomo, że wykona się tylko raz?!
Po spojrzeniu drugi raz zaczyna to mieć sens. Dzięki takiemu mechanizmowi można uzależnić wykonywanie kolejnych operacji od wyniku poprzednich w prosty sposób. W innym wypadku trzeba by było pisać masę zagnieżdżonych if‚ów. Ten poprzedni przykład zadziała tak samo jak to:
if( doSth() )
{
if( doSthElse() )
{
if( doAnotherThing() )
{
doLastThing();
}
}
}
Chyba nikogo nie muszę przekonywać, że poprzednie rozwiązanie było lepsze. To jest oczywiście najprostszy przykład, w którym różnica nie jest aż tak straszna, ale dla większej ilości instrukcji może to być problem.
Zwłaszcza jeżeli nie mamy funkcji takich jak doSth(), doSthElse() i wszystko wklepujemy do programu, wtedy takie zagnieżdżone if’y nie wyglądają zbyt ładnie 🙂
Moriturius's Devlog 
Przekonaj mnie. Dla mnie taka pętla, która nie jest pętlą, od razu wzmaga czujność wobec piszącego kod; spodziewam się po prostu, że będzie używał większej liczby dziwnych sztuczek.
A że zagnieżdżone ify są brzydkie? Usuń nadmiarowe nawiasy klamrowe i już jest znacznie lepiej. Przynajmniej dokładnie widać przebieg sterowania, bo takie nagłe i nadużywane breaki działają niemal jak goto Koniec.
@Xion: a gdyby tych ifow mialo byc 15? taka sztuczka wyglada lepiej nawet jesli pozbede sie tych nawiasow. Zreszta pisalem tez w poscie o tym, ze to doSth() to wcale nie musza byc konkretne funkcje tylko cale bloki instrukcji zapisujace wynik do jakiej zmiennej i potem dopiero jest sprawdzanie czy ten kawalek dal zamierzony efekt ( if(!status) break; ).
Jesli chodzi o goto, to uzywanie tej sztuczki jest wlasnie takim zamiennikiem zeby nikt sie nie czepial 😉 A przynajmniej na pierwszy rzut oka
Genialne! Dawno nie widziałem tak ciekawej notki na żadnym blogu. Wprawdzie aż się prosi żeby ten kod zamknąć w osobnej funkcji i zamiast break stosować return, ale sztuczka tak czy owak jest fajna.
@Reg: ale zauwaz, ze nie zawsze chce sie konczyc funkcje 🙂
Czasem mozna chciec po tym wszystkim zrobic jeszcze cos innego co jest niezalezne od tego czy wszystkie operacje w DWF zostaly wykonane czy nie
Witam, zauważyłem małą pomyłkę, w przykładzie z zagnieżdżonymi instrukcjami warunkowymi, nie powinno być negacji wyników zwracanych przez funkcje. Oczywiście zakłądając, że funkcje w obu przykładach robią to samo.
Pozdrawiam
@Maikeru: masz rację, dzięki 🙂 już poprawiam
Mam dokładnie takie samo zdanie na temat tego typu sztuczek jak Xion. Ale w sumie całkiem „cute” ;P