Czy to jest zła praktyka, aby użyć zwrotu w metodzie void?

Question

Wyobraźmy sobie następujący kod:

void DoThis() 
{ 
    if (!isValid) return; 

    DoThat(); 
} 

void DoThat() { 
    Console.WriteLine("DoThat()"); 
} 

Czy można użyć zwrotu wewnątrz metody void? Czy ma jakieś kary za wyniki? Albo lepiej byłoby napisać kod tak:

void DoThis() 
{ 
    if (isValid) 
    { 
     DoThat(); 
    } 
} 

Answer 1

Nie ma kary krytyki drugi kawałek kodu jest bardziej czytelny, a tym samym łatwiejsze do utrzymania.

Answer 2

Powrót w metodzie void nie jest zła, jest powszechną praktyką dla invert if statements to reduce nesting.

A mniej zagnieżdżania w twoich metodach poprawia czytelność kodu i łatwość konserwacji.

W rzeczywistości, jeśli masz metodę void bez instrukcji return, kompilator zawsze wygeneruje na końcu ret instruction.

Answer 3

Jest to całkowicie w porządku i nie ma "kary za wyniki", ale nigdy nie należy pisać instrukcji "if" bez nawiasów.

Zawsze

if(foo){ 
    return; 
} 

To sposób bardziej czytelny; i nigdy nie będziesz przypadkowo zakładać, że niektóre części kodu są w tym oświadczeniu, gdy nie są.

Answer 4

Zła praktyka ??? Nie ma mowy. W rzeczywistości zawsze lepiej jest obsłużyć sprawdzanie poprawności, zwracając z metody najwcześniej, jeśli sprawdzanie poprawności nie powiedzie się. Inaczej spowodowałoby to powstanie ogromnej liczby zagnieżdżonych ifs. Wcześniejsze kończenie poprawia czytelność kodu.

również sprawdzić odpowiedzi na podobne pytanie: Should I use return/continue statement instead of if-else?

Answer 5

W tym przypadku, drugi przykład jest lepszy kod, ale to nie ma nic wspólnego ze powrocie z funkcji void, to po prostu dlatego, że drugi kod jest bardziej bezpośredni. Ale powrót z funkcji pustki jest całkowicie w porządku.

Answer 6

To nie jest zła praktyka (z wszystkich powodów już wymienionych). Jednak im więcej zwrotów masz w metodzie, tym większe prawdopodobieństwo, że zostanie podzielona na mniejsze metody logiczne.

Answer 7

Nie zgodzę się z tym wszystkim, z tobą młodymi biczami.

Korzystanie z powrotu w środku metody, nieważne czy nie, jest bardzo złą praktyką, z przyczyn, które zostały wyraźnie sformułowane, prawie czterdzieści lat temu, przez zmarłego Edsgera W. Dijkstę, zaczynając od dobrze znanego " Oświadczenie GOTO uznane za szkodliwe "i kontynuowanie w" Programowaniu strukturalnym "autorstwa Dahl, Dijkstra i Hoare.

Podstawową zasadą jest, że każda struktura kontrolna i każdy moduł powinny mieć dokładnie jedną pozycję i jedno wyjście. Wyraźny powrót w środku modułu łamie tę zasadę i sprawia, że ​​znacznie trudniej jest zrozumieć stan programu, co z kolei znacznie utrudnia określenie, czy program jest poprawny, czy też nie (co jest znacznie silniejszą własnością niż "czy wydaje się działać, czy nie").

"Oświadczenie GOTO uznane za szkodliwe" i "Programowanie strukturalne" rozpoczęły rewolucję "Structured Programming" w latach siedemdziesiątych.Te dwie części to powody, dla których mamy teraz, jeśli nie, a zarazem i inne konstrukty kontroli jawnej dzisiaj i dlaczego instrukcje GOTO w językach wysokiego poziomu znajdują się na liście zagrożonych gatunków. (Moja osobista opinia jest taka, że ​​muszą znajdować się na liście gatunków wymarłych).

Warto zauważyć, że Modulator Przepływu Wiadomości, pierwszy kawałek oprogramowania militarnego, który PRZEDE WSZYSTKIM przeszedł testy akceptacyjne za pierwszym razem, bez żadnych odchyleń , zrzeczenie się lub "tak, ale" słownictwo, zostało napisane w języku, który nie miał nawet instrukcji GOTO.

Warto również wspomnieć, że Nicklaus Wirth zmienił semantykę instrukcji RETURN w Oberon-07, najnowszej wersji języka programowania Oberon, czyniąc ją końcową częścią deklaracji procedury wpisanej (tj. Funkcji) , a nie wykonywalne polecenie w treści funkcji. Jego wyjaśnienie zmiany mówiło, że zrobił to dokładnie dlatego, że poprzednia forma z 1-wyjściowego interfejsu programowania strukturalnego.

Answer 8

Pierwszy przykład to użycie instrukcji strażnika. Od Wikipedia:

w programowaniu komputerowym, strażnik jest wyrażenie logiczne, że musi ocenić true jeśli wykonanie programu jest nadal w oddziale w pytaniu.

Myślę, że posiadanie grupy strażników na szczycie metody to doskonale zrozumiały sposób programowania. Zasadniczo mówi się "nie wykonuj tej metody, jeśli któraś z nich jest prawdziwa".

Tak w ogóle byłoby to tak:

void DoThis() 
{ 
    if (guard1) return; 
    if (guard2) return; 
    ... 
    if (guardN) return; 

    DoThat(); 
} 

myślę, że jest o wiele bardziej czytelny następnie:

void DoThis() 
{ 
    if (guard1 && guard2 && guard3) 
    { 
    DoThat(); 
    } 
} 

Answer 9

Jest to kolejny wielki powód do korzystania strażników (w przeciwieństwie do kodu zagnieżdżonych) : Jeśli inny programista doda kod do funkcji, pracuje w bezpieczniejszym środowisku.

Rozważmy:

void MyFunc(object obj) 
{ 
    if (obj != null) 
    { 
     obj.DoSomething(); 
    } 
} 

kontra:

void MyFunc(object obj) 
{ 
    if (obj == null) 
     return; 

    obj.DoSomething(); 
} 

Teraz wyobraźmy sobie inny programista dodaje wiersz: obj.DoSomethingElse();

void MyFunc(object obj) 
{ 
    if (obj != null) 
    { 
     obj.DoSomething(); 
    } 

    obj.DoSomethingElse(); 
} 

void MyFunc(object obj) 
{ 
    if (obj == null) 
     return; 

    obj.DoSomething(); 
    obj.DoSomethingElse(); 
} 

Oczywiście, jest to uproszczony przypadek, ale programator posiada załamanie programu w pierwszym (kod zagnieżdżonych) np. W drugim przykładzie (wczesne wyjście ze strażnikami), gdy przejdziesz przez strażnika, twój kod jest bezpieczny przed niezamierzonym użyciem referencji zerowej.

Oczywiście świetny programista nie popełnia takich błędów (często). Lepiej jest jednak zapobiegać niż leczyć - możemy napisać kod w sposób całkowicie eliminujący potencjalne źródło błędów. Zagnieżdżanie zwiększa złożoność, więc najlepsze praktyki zalecają kod refaktoryzacji, aby zmniejszyć zagnieżdżanie.

Answer 10

Zgłaszanie wyjątków zamiast zwracania niczego, gdy obiekt ma wartość pustą itp.

Twoja metoda oczekuje, że obiekt nie będzie mieć wartości null, a nie jest tak, więc powinieneś wyrzucić wyjątek i pozwolić, aby to zadzwonił.

Ale wczesny powrót nie jest złą praktyką.