Odwróć polecenie "if", aby zmniejszyć zagnieżdżanie

Jest to nie tylko estetyczne, ale także zmniejsza maksymalny poziom zagnieżdżania wewnątrz metody. Jest to ogólnie uważane za plus, ponieważ sprawia, że metody łatwiejsze do zrozumienia (i rzeczywiście, Wiele static analiza narzędzia dostarczają miary tego jako jednego ze wskaźników jakości kodu).

Z drugiej strony, to również sprawia, że twoja metoda ma wiele punktów wyjścia, coś, co inna grupa ludzi uważa za nie.

Osobiście zgadzam się z Resharperem i pierwszą grupą (w języku, który ma wyjątki, uważam za głupie dyskutowanie o "wielu punktach wyjścia"; prawie wszystko może rzucić, więc istnieje wiele potencjalnych punktów wyjścia we wszystkich metodach).

Jeśli chodzi o wydajność : obie wersje powinny być równoważne (jeśli nie na poziomie IL, to na pewno po przejściu jittera z kodem) w każdym języku. Teoretycznie zależy to od kompilatora, ale praktycznie każdy powszechnie używany kompilator jest w stanie obsłużyć znacznie bardziej zaawansowane przypadki optymalizacji kodu niż ten.

To trochę religijny argument, ale Zgadzam się z Resharperem, że powinieneś woleć mniej zagnieżdżania. Uważam, że to przeważa nad negatywami posiadania wielu ścieżek powrotu z funkcji.

Głównym powodem mniejszej liczby zagnieżdżeń jest poprawa czytelności kodu i łatwości konserwacji . Pamiętaj, że wielu innych programistów będzie musiało przeczytać twój kod w przyszłości, a kod z mniejszą ilością wcięć jest ogólnie dużo łatwiejszy do odczytania.

Warunki wstępne są świetny przykład, gdzie jest w porządku, aby wrócić wcześnie na początku funkcji. Dlaczego obecność kontroli warunków wstępnych ma mieć wpływ na czytelność reszty funkcji?

Jeśli chodzi o negatywy dotyczące zwracania wielu razy z metody - debuggery są teraz dość potężne i bardzo łatwo jest dowiedzieć się dokładnie, gdzie i kiedy dana funkcja powraca.

posiadanie wielu zwrotów w funkcji nie wpłynie na utrzymanie praca programisty.

słaba czytelność kodu będzie.

Jak wspominali inni, nie powinno być hitu, ale są inne względy. Oprócz tych ważnych obaw, może to również otworzyć Cię na Gotcha w pewnych okolicznościach. Załóżmy, że masz do czynienia z double zamiast:

public void myfunction(double exampleParam){
    if(exampleParam > 0){
        //Body will *not* be executed if Double.IsNan(exampleParam)
    }
}

Kontrast zpozornie równoważna inwersja:

public void myfunction(double exampleParam){
    if(exampleParam <= 0)
        return;
    //Body *will* be executed if Double.IsNan(exampleParam)
}

Więc w pewnych okolicznościach to, co wydaje się być prawidłowo odwrócone if może nie być.

Pomysł powrotu tylko na końcu funkcji pochodzi z czasów, zanim języki miały wsparcie dla WYJĄTKÓW. Umożliwiło to programom poleganie na umieszczeniu kodu czyszczenia na końcu metody, a następnie upewnieniu się, że zostanie on wywołany, a inny programista nie ukryje zwrotu w metodzie, która spowodowała pominięcie kodu czyszczenia. Pominięty kod czyszczenia może spowodować wyciek pamięci lub zasobów.

Jednak w języku, który obsługuje wyjątki, zapewnia nie ma takich gwarancji. W języku, który obsługuje wyjątki, wykonanie dowolnej instrukcji lub wyrażenia może spowodować przepływ sterowania, który powoduje zakończenie metody. Oznacza to, że Sprzątanie musi odbywać się za pomocą słów kluczowych finally lub za pomocą słów kluczowych.

W każdym razie mówię, że myślę, że wiele osób cytuje wytyczne "tylko powrót na końcu metody", nie rozumiejąc, dlaczego było to kiedykolwiek dobrą rzeczą do zrobienia, a zmniejszenie zagnieżdżania w celu poprawy czytelności jest prawdopodobnie lepszym celem.

Chciałbym dodać, że istnieje nazwa dla odwróconej klauzuli If ' s-Guard. Używam go, kiedy tylko mogę.

Nienawidzę czytać kodu tam, gdzie jest jeśli na początku, dwa ekrany kodu i nic więcej. Odwróć jeśli i wróć. W ten sposób nikt nie będzie tracił czasu na przewijanie.

Http://c2.com/cgi/wiki?GuardClause

Wpływa nie tylko na estetykę, ale także zapobiega zagnieżdżaniu się kodu.

Może faktycznie działać jako warunek wstępny, aby zapewnić, że Twoje dane są również ważne.

Jest to oczywiście subiektywne, ale myślę, że zdecydowanie poprawia się w dwóch punktach:

• jest teraz oczywiste, że twoja funkcja nie ma nic do roboty, jeśli condition posiada.
Utrzymuje poziom zagnieżdżenia w dół. Zagnieżdżanie rani czytelność bardziej niż myślisz.

Wiele punktów zwrotnych było problemem w C (i w mniejszym stopniu w C++), ponieważ zmuszały Cię do duplikowania kodu przed każdym z punktów zwrotnych. Z garbage collection, the try | finally konstruuj i using bloki, naprawdę nie ma powodu, dla którego powinieneś się ich bać.

Pod względem wydajności nie będzie zauważalnej różnicy między tymi dwoma podejściami.

Ale kodowanie to coś więcej niż wydajność. Przejrzystość i łatwość konserwacji są również bardzo ważne. A w takich przypadkach, gdzie nie wpływa to na wydajność, liczy się tylko to.

Istnieją konkurencyjne szkoły myślenia, które podejście jest lepsze.

Jednym z nich jest ten, o którym wspominali inni: drugie podejście zmniejsza poziom zagnieżdżania, co poprawia przejrzystość kodu. Jest to naturalne w stylu imperatywnym: gdy nie masz już nic do roboty, równie dobrze możesz wrócić wcześniej.

Inny pogląd, z perspektywy bardziej funkcjonalnego stylu, jest taki, że metoda powinna mieć tylko jeden punkt wyjścia. Wszystko w języku funkcjonalnym jest wyrażeniem. Więc jeśli wypowiedzi muszą zawsze mieć klauzulę else. W przeciwnym razie wyrażenie if nie zawsze miałoby wartość. Tak więc w stylu funkcjonalnym pierwsze podejście jest bardziej naturalne.

Klauzule ochronne lub warunki wstępne (jak zapewne widzisz) sprawdzają, czy dany warunek jest spełniony, a następnie przerywają przepływ programu. Są świetne do miejsc, w których naprawdę interesuje Cię tylko jeden wynik if Oświadczenia. Więc zamiast mówić:

if (something) {
    // a lot of indented code
}

Odwracasz warunek i łamiesz, jeśli ten odwrócony warunek jest spełniony

if (!something) return false; // or another value to show your other code the function did not execute

// all the code from before, save a lot of tabs

return nie jest tak brudny jak goto. Pozwala przekazać wartość, aby pokazać resztę kodu, że funkcja nie mógł uciec.

Zobaczysz najlepsze przykłady, gdzie można to zastosować w Warunkach zagnieżdżania:

if (something) {
    do-something();
    if (something-else) {
        do-another-thing();
    } else {
        do-something-else();
    }
}

Vs:

if (!something) return;
do-something();

if (!something-else) return do-something-else();
do-another-thing();

Znajdziesz kilka osób argumentujących, że pierwszy jest czystszy, ale oczywiście jest całkowicie subiektywny. Niektórzy programiści lubią wiedzieć, w jakich warunkach coś działa przez wcięcia, podczas gdy ja wolałbym zachować przepływ metody liniowy.

Jest tu kilka dobrych punktów, ale wiele punktów zwrotnych może być również nieczytelnych, Jeśli metoda jest bardzo długa. Mając to na uwadze, jeśli zamierzasz używać wielu punktów zwrotnych, upewnij się, że twoja metoda jest krótka, w przeciwnym razie bonus czytelności wielu punktów zwrotnych może zostać utracony.

Przedstawienie składa się z dwóch części. Masz wydajność, gdy oprogramowanie jest w produkcji, ale chcesz również mieć wydajność podczas opracowywania i debugowania. Ostatnią rzeczą, jakiej chce deweloper, jest "czekanie" na coś trywialnego. W końcu kompilacja z włączoną optymalizacją spowoduje powstanie podobnego kodu. Więc dobrze jest znać te małe sztuczki, które opłacają się w obu scenariuszach.

Sprawa w pytaniu jest jasna, ReSharper jest poprawny. Zamiast zagnieżdżać if wypowiedzi i tworząc nowy zakres w kodzie, na początku metody ustawiasz jasną regułę. Zwiększa czytelność, będzie łatwiejsze w utrzymaniu i zmniejsza ilość reguł, które trzeba przesiać, aby znaleźć, gdzie chcą się udać.

Osobiście wolę tylko 1 punkt wyjścia. Jest to łatwe do osiągnięcia, jeśli utrzymasz swoje metody krótkie i do rzeczy, i zapewnia przewidywalny wzór dla następnej osoby, która pracuje nad Twoim kodem.

Np.

 bool PerformDefaultOperation()
 {
      bool succeeded = false;

      DataStructure defaultParameters;
      if ((defaultParameters = this.GetApplicationDefaults()) != null)
      {
           succeeded = this.DoSomething(defaultParameters);
      }

      return succeeded;
 }

Jest to również bardzo przydatne, jeśli chcesz sprawdzić wartości pewnych zmiennych lokalnych w funkcji przed jej zakończeniem. Wszystko, co musisz zrobić, to umieścić punkt przerwania na ostatnim powrocie i masz gwarancję, że go trafisz(chyba że wyjątek zostanie wyrzucony).

Wiele dobrych powodów dotyczących Jak wygląda kod . Ale co z wynikami ?

Przyjrzyjmy się jakiemuś kodowi C# i jego postaci skompilowanej IL:

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length == 0) return;
        if ((args.Length+2)/3 == 5) return;
        Console.WriteLine("hey!!!");
    }
}

Ten prosty fragment można skompilować. Możesz otworzyć wygenerowany .plik exe z ildasm i sprawdź jaki jest wynik. Nie będę zamieszczał wszystkich rzeczy asemblera, ale opiszę wyniki.

Wygenerowany kod IL wykonuje następujące czynności:

1. jeśli pierwszy warunek jest false, przeskakuje do kodu gdzie jest drugi.
2. jeśli to prawda, przeskakuje do ostatniej instrukcji. (Uwaga: ostatnia instrukcja jest zwrotem).
3. w drugim warunku to samo dzieje się po obliczeniu wyniku. Porównaj i: dostałem się do konsoli.WriteLine if false lub to the end if this is true.
4. Wydrukuj wiadomość i wróć.

Wygląda na to, że kod przeskoczy do końca. Co jeśli zrobimy normalne if z zagnieżdżonym kodem?

using System;

public class Test {
    public static void Main(string[] args) {
        if (args.Length != 0 && (args.Length+2)/3 != 5) 
        {
            Console.WriteLine("hey!!!");
        }
    }
}

Wyniki są dość podobne w IL instrukcje. Różnica polega na tym, że zanim nie było do skoków na warunek: jeśli false przejść do następnego kawałka kodu, jeśli true przejść do then end. A teraz kod IL płynie lepiej i ma 3 skoki (kompilator zoptymalizował to trochę): 1. Pierwszy skok: gdy długość wynosi 0 do części, w której kod przeskakuje ponownie (trzeci skok) do końca. 2. Po drugie: w środku drugiego warunku, aby uniknąć jednej instrukcji. 3. Po trzecie: jeśli drugi warunek jest fałszywy, przejdź do końca.

W każdym razie licznik programu zawsze będzie skakać.

To jest po prostu kontrowersyjne. Nie ma "porozumienia między programistami" w kwestii wczesnego powrotu. To zawsze subiektywne, z tego co wiem.

Jest to możliwe, aby argument wydajności, ponieważ lepiej mieć warunki, które są napisane tak, że są najczęściej prawdziwe; można również argumentować, że jest jaśniejszy. Z drugiej strony tworzy zagnieżdżone testy.

Myślę, że nie dostaniesz jednoznacznej odpowiedzi na to pytanie.

W teorii odwrócenie if może prowadzić do lepszej wydajności, jeśli zwiększy wskaźnik trafień przewidywania gałęzi. W praktyce wydaje mi się, że bardzo trudno jest dokładnie wiedzieć, jak będzie zachowywać się przewidywanie gałęzi, szczególnie po kompilacji, więc nie robiłbym tego w moim codziennym rozwoju, chyba że piszę kod assembly.

Więcej o przewidywaniu gałęzi tutaj .

Istnieje wiele wnikliwych odpowiedzi tam już, ale nadal, chciałbym skierować do nieco innej sytuacji: zamiast warunku wstępnego, który powinien być umieszczony na górze funkcji rzeczywiście, pomyśl o inicjalizacji krok po kroku, gdzie trzeba sprawdzić, czy każdy krok, aby odnieść sukces, a następnie kontynuować następny. W tym przypadku nie można sprawdzić wszystkiego na górze.

Mój kod był naprawdę nieczytelny podczas pisania aplikacji hosta ASIO z Asiosdk Steinberga, ponieważ paradygmat zagnieżdżania. Poszło jak osiem poziomów głęboko i nie widzę tam wady projektowej, o czym wspomniał powyżej Andrew Bullock. Oczywiście, mogłem spakować jakiś wewnętrzny kod do innej funkcji, a następnie zagnieżdżać pozostałe poziomy, aby uczynić go bardziej czytelnym, ale wydaje mi się to raczej przypadkowe.

Zamieniając zagnieżdżanie klauzulami guard, odkryłem nawet moje błędne przekonanie dotyczące części kodu czyszczenia, które powinno nastąpić znacznie wcześniej w funkcji zamiast na końcu. Z zagnieżdżonymi gałęziami nigdy bym tego nie widział, można nawet powiedzieć, że doprowadziły do mojego błędnego przekonania.

Więc może to być kolejna sytuacja, w której odwrócony ifs może przyczynić się do jaśniejszego kodu.

Unikanie wielu punktów wyjścia Może prowadzić do wzrostu wydajności. Nie jestem pewien co do C# ale w C++ nazwana Optymalizacja zwracanej wartości (Copy Elision, ISO C++ '03 12.8/15) zależy od posiadania jednego punktu wyjścia. Ta optymalizacja pozwala uniknąć kopiowania konstruowania wartości zwrotu (w konkretnym przykładzie nie ma to znaczenia). Może to prowadzić do znacznego wzrostu wydajności w ciasnych pętlach, ponieważ zapisujesz konstruktor i destruktor za każdym razem, gdy wywoływana jest funkcja.

Ale w 99% przypadków zapisanie dodatkowych wywołań konstruktora i destruktora nie jest warte utraty czytelności zagnieżdżone if bloki wprowadzają (jak zauważyli inni).

To kwestia opinii.

Moim normalnym podejściem byłoby unikanie jednoliniowych if i zwracanie w środku metody.

Nie chcesz linii, jak sugeruje wszędzie w Twojej metodzie, ale jest coś do powiedzenia, aby sprawdzić kilka założeń na górze swojej metody, i tylko wykonując swoją rzeczywistą pracę, jeśli wszystkie przechodzą.

Moim zdaniem early return jest w porządku, jeśli po prostu zwracasz void (lub jakiś bezużyteczny kod zwrotu, którego nigdy nie sprawdzisz) i może poprawić czytelność, ponieważ unikasz zagnieżdżania i jednocześnie wyraźnie stwierdzasz, że twoja funkcja jest wykonywana.

Jeśli rzeczywiście zwracasz wartość return-zagnieżdżanie jest zwykle lepszym sposobem, ponieważ zwracasz wartość return tylko w jednym miejscu (na końcu-duh), co może sprawić, że Twój kod będzie łatwiejszy do utrzymania w wielu przypadkach.

Myślę, że to zależy od tego, co wolisz, jak wspomniano, nie ma ogólnej zgody afaik. Aby zmniejszyć rozdrażnienie, możesz zmniejszyć tego rodzaju ostrzeżenie do "podpowiedzi"

Moim zdaniem zwrot "w środku funkcji" nie powinien być tak "subiektywny". Powód jest dość prosty, weź ten kod:

    function do_something( data ){

      if (!is_valid_data( data )) 
            return false;


       do_something_that_take_an_hour( data );

       istance = new object_with_very_painful_constructor( data );

          if ( istance is not valid ) {
               error_message( );
                return ;

          }
       connect_to_database ( );
       get_some_other_data( );
       return;
    }

Może pierwszy "powrót" nie jest tak intuicyjny, ale to naprawdę oszczędność. Istnieje zbyt wiele " pomysłów "na temat czystych kodów, które po prostu potrzebują więcej praktyki, aby stracić swoje" subiektywne " złe pomysły.

Jest kilka zalet tego rodzaju kodowania, ale dla mnie wielką wygraną jest to, że jeśli możesz szybko wrócić, możesz poprawić szybkość swojej aplikacji. IE wiem, że ze względu na warunek wstępny X, że mogę wrócić szybko z błędem. Pozwala to najpierw pozbyć się błędów i zmniejsza złożoność kodu. W wielu przypadkach, ponieważ rurociąg cpu może być teraz czystszy, może zatrzymać awarie lub przełączniki rurociągu. Po drugie, jeśli jesteś w pętli, zerwanie lub powrót szybko może zaoszczędzisz dużo procesora. Niektórzy programiści używają niezmienników pętli do tego typu szybkiego wyjścia, ale w ten sposób można złamać rurociąg procesora, a nawet stworzyć problem z szukaniem pamięci i oznaczać, że procesor musi załadować się z zewnątrz pamięci podręcznej. Ale zasadniczo myślę, że powinieneś zrobić to, co zamierzałeś, to jest zakończyć pętlę lub funkcję, a nie tworzyć złożoną ścieżkę kodu tylko po to, aby zaimplementować jakieś abstrakcyjne pojęcie poprawnego kodu. Jeśli jedynym narzędziem, które masz, jest młotek, to wszystko wygląda jak gwóźdź.