Wczoraj rozgorzała gorąca dyskusja - dzisiaj temat nawiązujący.
“Nie przekazujemy null. Zwracanie wartości null z metod jest niedobrą praktyką, ale przekazywanie wartości null do metod jest jeszcze gorsze. O ile nie korzystamy z API, które oczekuje wartości null, i o ile mamy taką możliwość, powinniśmy unikać przekazywania null we własnym kodzie. [...] W większości języków programowania nie istnieje dobra metoda obsługi wartości null przypadkowo przekazywanych przez wywołującą procedurę. Z tego powodu racjonalnym podejściem jest zakazanie przekazywania wartości null.”
@FEAofTruss: Nadal to nic nie zmienia. Może takie zabawy w językach wysokopoziomowych się sprawdzają, ale w embedded nie bardzo. Zwracanie kolekcji, która ma albo 1 element albo 0 też jest dziwne.
Może po prostu lepiej sensowniej sprawdzać, czy jest nullem? Lepiej organizować kod w takich przypadkach?
@krasnoludkolo: gdzie potem jedna odwołuje się do drugiej z domyślnym parametrem null, żeby nie mnożyć kodu...
@Razi91 zazwyczaj jak coś jest nullem to coś innego się dzieje już nullem nie jest. W jednej metodzie robisz właśnie to i ewentualnie odwołuje się do drugiej (choć nie zawsze) Zauwaz też że książka jest do Javy więc wysokopoziomowego gdzie wydajność nie jest aż tak ważna
@FEAofTruss: Kompletnie z tym się nie zgodzę. Już wczoraj o tym pisałem. Czasami przypisywanie wartości null jest wskazane na frontendzie, gdzie istnieje też undefined. Często jako null oznacza się obiekty, kolekcje które nie powinny zostać zainicjalizowane, ale oznaczamy je jako null żeby właśnie wiedzieć, że są takie z jakiegoś powodu. Wtedy widząc, że coś jest undefined wiemy, że po prostu coś jest #!$%@?.
@krasnoludkolo: ee.. Przykłady są z Javy, porady są ogólne. Fakt że w assemblerze się tak nie da nie znaczy że taki C++ nie może. I miejcie litość, czasy performance na zachowaniu bita minęły. Przypadki gdzie musisz to pilnowac to też radość, a i tam stabilność może być ważniejsza.
@Razi91: przeciążyć metodę, przekazać wartość domyślną inną niż null (np. 0, 1 czy pusty ciąg znaków, cokolwiek ma sens w danym kontekście), zastosować wzorzec NullObject czy przeorganizować trochę metody tak żeby nie był potrzebny opcjonalny argument (np. podzielić je na 2 metody publiczne wywołujące prywatną część wspólną)
Ogólnie możliwości jest masa, przekazanie nulla może wydawać się najprostsze ale to raczej najgorsze z rozwiązań, potem
@sakfa: w js to chyba nawet bardziej trzeba uważać, bo exception zauwazysz, a w js gdzieś na koncu w widoku dostaniesz undefined5 czy coś w ten deseń. c# też ładnie rady wykorzystuje. Pewnie skryptowe mają gorzej.
Ale ogólnie to wpis taki ze jakby ktoś pytał to z Tobą bym mógł pracować. Bo niektórzy to w koszarach się pojawiają jakby mieli do projektu dołączyć :D
Wczoraj rozgorzała gorąca dyskusja - dzisiaj temat nawiązujący.
“Nie przekazujemy null.
Zwracanie wartości null z metod jest niedobrą praktyką, ale przekazywanie wartości null do metod jest jeszcze gorsze. O ile nie korzystamy z API, które oczekuje wartości null, i o ile mamy taką możliwość, powinniśmy unikać przekazywania null we własnym kodzie. [...] W większości języków programowania nie istnieje dobra metoda obsługi wartości null przypadkowo przekazywanych przez wywołującą procedurę. Z tego powodu racjonalnym podejściem jest zakazanie przekazywania wartości null.”
[Więcej infomacji]
#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev
Podobało się? To zaplusuj i zapisz się do wołania (link w stopce)
************
[Chcesz być wołany?]
Możesz zapisać/wypisać się klikając na nazwę listy.
Sponsor: Grupa Facebookowa z promocjami z chińskich sklepów
Masz problem z działaniem listy? A może pytanie? Pisz do IrvinTalvanen
! @FEAofTruss @mikasjp @vorio @MAT3N @Trustm3 @wszystkiefajnenickisazajete @avangarda @mozetenbedziewolny @PhatFarm05 @owocbananowca @pan_cziken @Tojtek @dotnetboy @Anon95 @kMarek @JachuPL @maykel @ugotowany_kamien @dyktek @Movet @se_czytam @MaNiEk1 @pieczony_ziemniaczek @ogib @adish24 @denis-szwarc @krypsi @nonsplit @krasnoludkolo @Gigantyczny_Bebech @legitAccount @hit_malinowy @Efilnikufesin @kafapre @skim @udips @paganek @emaq @
if (val != null)
? Rada trochę jak „nie jest zalecane aby popełniać błędy”. Jak parametr jest opcjonalny, to co trzeba zrobić?Może po prostu lepiej sensowniej sprawdzać, czy jest nullem? Lepiej organizować kod w takich przypadkach?
@krasnoludkolo: gdzie potem jedna odwołuje się do drugiej z domyślnym parametrem
null
, żeby nie mnożyć kodu...Rady są fajne, ale nie zawsze się
Zauwaz też że książka jest do Javy więc wysokopoziomowego gdzie wydajność nie jest aż tak ważna
W sumie te wszystkie złote myśli powinieneś chyba
@FEAofTruss
Chyba warto dodać że książka tyczy się Javy i wiekszosc porad tyczy się tego języka
@nilphilus
Okej, bardziej są to porady do szeroko pojętego OOP
@Razi91: przeciążyć metodę, przekazać wartość domyślną inną niż null (np. 0, 1 czy pusty ciąg znaków, cokolwiek ma sens w danym kontekście), zastosować wzorzec NullObject czy przeorganizować trochę metody tak żeby nie był potrzebny opcjonalny argument (np. podzielić je na 2 metody publiczne wywołujące prywatną część wspólną)
Ogólnie możliwości jest masa, przekazanie nulla może wydawać się najprostsze ale to raczej najgorsze z rozwiązań, potem
Ale ogólnie to wpis taki ze jakby ktoś pytał to z Tobą bym mógł pracować. Bo niektórzy to w koszarach się pojawiają jakby mieli do projektu dołączyć :D