Rozważ ten fragment kodu:
if (x == 1)
{
throw "no good; aborting" ;
}
[... more code ...]
Teraz rozważ ten kod:
if (x == 1)
{
throw "no good; aborting" ;
}
else
{
[... more code ...]
}
Oba przypadki działają dokładnie w ten sam sposób. Pierwszy przypadek ma tę zaletę, że nie trzeba „otaczać” reszty kodu w pliku else
. Drugi ma tę zaletę, że postępuje zgodnie z praktyką jawnego posiadania else
dla każdego if
.
Czy ktoś może przedstawić jakieś solidne argumenty na korzyść jednego nad drugim?
coding-style
exceptions
Rlandster
źródło
źródło
else
wydaje się nieprawdziwa. Dość często po prostu nie ma nic do włożenia welse
blok, chyba że się pochylisz.if
potrzebujeelse
. Ostatni programista, który pracował na naszej bazie kodu, przestrzegał tego sztywno ( no cóż, czasami ... to rodzaj schizofrenika ). W rezultacie mamy wiele całkowicie bezsensownychelse { /* do nothing */ }
bloków zaśmiecających kod ...Odpowiedzi:
Nie należy dodawać
else
poif
gałęziach, które bezwarunkowo przerywają przepływ sterowania , takich jak te zawierające athrow
lub areturn
. Poprawiłoby to czytelność twojego programu, usuwając niepotrzebny poziom zagnieżdżania wprowadzony przezelse
gałąź.To, co wygląda mniej więcej tak samo z jednym,
throw
staje się naprawdę brzydkie, gdy zostaje zaatakowanych kilka rzutów z rzędu:Ten fragment kodu robi to samo, ale wygląda znacznie lepiej:
źródło
else if
.if
testuje pojedynczy warunek i radzi sobie z nim, jeśli warunek jest prawdziwy, i jeśli nie jest jakaś alternatywna rzecz, która musi się zdarzyć, jeśli warunek jest fałszywy,else if
s są niepotrzebne. W moim biurze jest termin na kod, taki jak pierwszy fragment dasblinkenlight: „ maszyny pachinko ”.else
.Nazwałbym praktykę „wyraźne inaczej”, którą nazywacie anty-wzorcem, ponieważ przesłania fakt, że nie ma kodu specjalnego przypadku jako innego dla waszego if.
Czytelność / łatwość konserwacji jest ogólnie poprawiona, gdy przeważnie masz tylko niezbędne konstrukcje przepływu kodu i minimalizujesz je. Oznacza to nadmiarowe wady i if, które dodadzą zakres do całej funkcji, utrudniają śledzenie i utrzymanie jej.
Powiedz na przykład, że masz tę funkcję:
Teraz pojawia się wymóg, że podczas konfiguracji należy również określić indeks typu / typu oblogon, istnieje wiele zakresów, w których ktoś może umieścić ten kod i skończyć z nieprawidłowym kodem, tj.
Porównaj to z tym, czy oryginalny kod został napisany z minimalnymi potrzebnymi i minimalnymi konstrukcjami kontroli przepływu.
Znacznie trudniej byłoby teraz przypadkowo umieścić coś w niewłaściwym zakresie lub skończyć rozdętymi zakresami, powodując dublowanie w długim okresie wzrostu i utrzymania tej funkcji. Ponadto jest oczywiste, jakie są możliwe przepływy przez tę funkcję, więc poprawiono czytelność.
Wiem, że ten przykład jest nieco wymyślony, ale wiele razy widziałem
Dlatego sformalizowanie tych reguł dotyczących konstrukcji kontroli przepływu może pomóc ludziom rozwinąć intuicję niezbędną do wyczuwania czegoś, kiedy zaczną pisać kod w ten sposób. Wtedy zaczną pisać ...
źródło