@pawelkor - w komentarzu do wypowiedzi jest za mało miejsca, stąd oddzielna odpowiedź.
Nie mogę się zgodzić co do tezy, że nie należy wyskakiwać z funkcji w jej środku. Wprost przeciwnie, przynajmniej w nowoczesnych językach programowania. To jest doskonały przykład sytuacji, w której powtarzamy i kultywujemy pewne zasady mimo że już dawno zapomnieliśmy, dlaczego były one istotne. Zanim więc podam powody, dla których return można wsadzać gdzie się chce, napiszę skąd wzięło się przykazanie, że funkcja powinna mieć jeden punkt wyjścia i dlaczego w nowoczesnych językach jest ono już nieaktualne.
Głównym powodem, dla którego taka reguła się pojawiła, było zarządzanie pamięcią, uchwytami plików, ogólnie - cennymi zasobami, które trzeba zwalniać gdy się przestaje z nich korzystać. Mając kilka punktów wyjścia z funkcji bardzo łatwo było zrobić błąd i czegoś nie zwolnić. Mając jeden punkt wyjścia, gdy taki błąd wystąpił, wystarczyło sprawdzić w tym jednym miejscu - bez analizowania całej logiki powyżej. Nawet w tym przypadku jednak debugowanie tego typu problemów było bardzo trudne, stąd się pojawiło przykazanie - nie będziesz miał punktów wyjścia, poza jednym.
Dzisiaj, gdy dysponujemy językami automatycznie zarządzającymi pamięcią, wycieku pamięci tak nie uzyskamy (choć są inne na to metody, hehe) - po prostu gdy lokalna referencja wewnątrz funkcji przestanie być aktualna, garbage collector zwolni alokowaną pamięć. Zatem jeden argument automatycznie spada z listy.
Poza tym mamy dwie fajne konstrukcje - w C# to jest try...finally oraz using które pozwalają na zarządzanie kosztownymi zasobami w postaci zgrabnych bloków. Zwolnienie takiego zasobu - uchwytu do pliku, połączenia z bazą danych, itd. - następuje automatycznie po wystąpieniu wyjątku (finally) lub przy wyjściu z bloku (using) - nawet w jego środku. Zatem o to też już nie musimy się martwić!
To wszystko pozwala spłaszczać funkcje. Jeżeli musimy zrobić rzecz A lub B w zależności od jakiegoś warunku - sprawdźmy warunek, jeśli jest spełniony zróbmy rzecz A i zwróćmy wynik. Koniec. Upraszczamy logikę. Jeżeli jakieś miejsce w kodzie jest finalne dla pewnej ścieżki przetwarzania, to niech będzie kategorycznie finalnym, przy użyciu return. W ten sposób dbamy o to, że nigdzie dalej nie wykona się żaden kod który nie powinien, tylko dlatego że przegapiliśmy jakiś warunek, źle zagnieździliśmy bloki itd. Bez mnożenia if-ów, elsów, wyciągania zmiennych poza blok w którym obowiązują tylko po to, by dotrwały do końcowego return... Jeżeli to nie jest czytelniejsze, to nie wiem co jest.
Tak samo - wyjątki. Każde miejsce gdzie rzucamy wyjątkiem jest punktem wyjścia z funkcji, mimo że nie zwracamy tu żadnego wyniku. Ktoś przeciwko temu protestuje? Chyba nie, wyjątki zadomowiły się w naszych językach już dawno. Zatem czemu nie pójść krok dalej i nie porzucić całkiem tej całej farsy z jednym punktem wyjścia na końcu?
