@niedorzecznybubr: imho to jest kwestia estetyki, zależy od intencji autora i tego jak wygląda rzeczywisty kod. else często zwiększa czytelność kodu, nawet jeśli jest zbędny. branche kodu są wtedy bardziej ewidentne i bardziej "odseparowane" od siebie.
@ly000: Nie, dodaj kolejny warunek do pierwszej wersji w tym samym podejsciu i sprawdz czytelnosc kodu, pierwszy lepszy artykul ktory wyczerpuje ten temat.
Jak masz proste sprawdzenie albo jedno albo drugie, to jedziesz bez elsa. Ale jeśli sprawdzasz, czy jedno zaprzecza drugiemu to lepiej polecieć z elsem.
Wydajność: Pewnie zależy od zagnieżdżenia - trzebaby rozkminić, czy przypadkiem nie wpływa na przeliczanie wszystkich instrukcji warunków kiedy nie ma jasno powiedziane, którą ścieżką ma pójść.
Czytelność: Jakbym przeglądał czyjeś unit testy i widział zadeklarowane elsy, to pewnie wygodniej byłoby się domyślić "co autor miał na
@niedorzecznybubr: powszechnie stosowane jest bez else. Spotkałem się nawet z zadaniem w trakcie rozmowy rekrutacyjnej typu "popraw kod", gdzie jedną z oczekiwanych rzeczy było usunięcie takich właśnie else żeby zmniejszyć ilość zagnieżdżania.
if (condition) {
return x;
} else {
return y;
}
czy
if (condition) {
return x;
}
return y;
#programowanie #programista15k #pracait #pytaniedoeksperta
Która wersja?
@niedorzecznybubr: to nie jest kwestia preferencji, nalezy stosowac wczesne returny :)
return condition ? x : y;
@ly000: Nie, dodaj kolejny warunek do pierwszej wersji w tym samym podejsciu i sprawdz czytelnosc kodu, pierwszy lepszy artykul ktory wyczerpuje ten temat.
Nie, to jest kwestia jakosci kodu.
@szubke: no a jak babcia będzie miała wąsy to będzie dziadkiem. dlaczego zmieniasz sobie dowolnie treść pytania?
a jakość kodu może być oczywiście mierzona w sposób obiektywny.
w tym przypadku jawny else zwiększa jakość kodu, bo masz jawnie pokazane ścieżki kodu. w drugim
@ly000: podalem ci konkretny artykul na ten temat, czym jest early return
nie, early return to jedna z zasad w obrebie clean code
Jak masz proste sprawdzenie albo jedno albo drugie, to jedziesz bez elsa. Ale jeśli sprawdzasz, czy jedno zaprzecza drugiemu to lepiej polecieć z elsem.
Wydajność: Pewnie zależy od zagnieżdżenia - trzebaby rozkminić, czy przypadkiem nie wpływa na przeliczanie wszystkich instrukcji warunków kiedy nie ma jasno powiedziane, którą ścieżką ma pójść.
Czytelność: Jakbym przeglądał czyjeś unit testy i widział zadeklarowane elsy, to pewnie wygodniej byłoby się domyślić "co autor miał na
@szubke: Chyba że musisz stosować misrę, albo inne standardy, gdzie wymagany jest "single point of return".