Wpis z mikrobloga

21/100 dni z książką

Nie zwracamy null.
Nie zliczę widzianych przeze mnie aplikacji, w których niemal każdy wiersz kodu zawierał test wartości null. [...] Gdy zwracamy wartość null, w rzeczywistości tworzymy sobie dodatkową pracę i powodujemy problemy w funkcjach wywołujących. W takich przypadkach brak jednego testu wartości null powoduje, że aplikacja wymyka się spod kontroli.”

[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?]
  • 93
  • Odpowiedz
@Lewo: Wyjątki nie do tego służą :)

O Optionalach możesz myśleć w taki sposób.

Jeżeli masz List to wiesz, że masz się spodziewać tego, że będziesz mieć wiele, uporządkowanych integerów w danej zmiennej.

Jeżeli masz Optional to wiesz, że w środku mogą być dwie możliwości: albo będzie pewna wartość (Some(wartość)), albo będzie pusto (Nothing / None). Typ daje nam taką informację.

I po co to? A na co to komu? Ta
  • Odpowiedz
@krasnoludkolo: A nie pojawiają się za to nowe ClassCastException? Pytanie nieironiczne, pytam z ciekawości bo ni używam. NPE to sam w sobie nic strasznego. Sygnalizuje tylko, że gdzieś coś było nieprzemyślane. Zawsze automatyzacja procesu odbije się na wydajności/elastyczności.
  • Odpowiedz
Jak masz aplikację która obsługuje bardzo dużo klientów, a infrastruktura jest taka, że normalnie wytrzymuje, ale są momenty natężonego ruchu parę razy do roku to wtedy wszystko ma znaczenie.


@ZasilaczKomputerowy: polecam jednak zainwestować w jakiś autoscaling czy coś co dołoży więcej maszyn jak są potrzebne, a nie szukanie 0.1% wzrostu wydajności na zastępowaniu Optionali nullem.

Zresztą powiedziałbym też ze jak masz duży ruch to tym bardziej nie chcesz żeby nagle aplikacja
  • Odpowiedz
@kwareczek książka była pisana jeszcze w czasach starych jav bez optionali itp plus zapewniam cię że w samej treści książki jest to dokładniej rozpisane. Co dokładnie w tym fragmencie Ci nie pasuje?
  • Odpowiedz
@sakfa:

zastępowaniu Optionali nullem.

Nie to miałem na myśli. Autoscaling jest spoko jak masz aplikację gdzieś w jakimś amazonie, a nie u klienta w firmie (wymogi bezpieczeństwa).

Zresztą powiedziałbym też ze jak masz duży ruch to tym bardziej nie chcesz żeby nagle aplikacja pluła NullPointerException


Rzeczy są dobrze przetestowane. Raczej serwis się nudzi pod tym względem.
  • Odpowiedz
@ZasilaczKomputerowy: więc generalnie zgadzam się że skoro nie ma problemów to nie ma co ruszać :)

Z dobrymi praktykami tak jest że to tylko dobre praktyki, nie trzeba się do nich stosować żeby napisać dobry kod. Zwłaszcza jeżeli pisze go zespół dobrych i doświadczonych inżynierów. Ale zaczynają być co raz ważniejsze gdy w zespole jest więcej juniorów albo - o zgrozo - cały fragment kodu jest pisany tylko przez juniora a
  • Odpowiedz
@ZasilaczKomputerowy ale zwróć uwagę jak rośnie Ci narzut że przy każdej metodzie która coś zwraca musisz usiąść i się zastanowić czy zwróci nulla czy nie. Wiem, do dokumentacja ale... fajnie jak jest a jeszcze lepiej jak jest aktualna ( ͡º ͜ʖ͡º)
  • Odpowiedz
@ZasilaczKomputerowy: no tak, ale tu Optional też jest praktyczniejszy

Wolałbym żeby mój junior ślepo dodawał wszędzie niepotrzebne Optionale (bo to łatwo wychwycić na CR) niż pisał metody które zwracają null (i zastanawiaj się potem czy aby na pewno wszędzie sprawdził... Jak masz zapewne przed oczami tylko diff tej konkretnej zmiany i nie wiesz co się dalej dzieje z tą wartością zwracaną). Jak zwróci Optional to przynajmniej wiesz że wszystkie użycia tej
  • Odpowiedz
@krasnoludkolo: Jak tak sięgnę pamięcią to raczej nie mam z tym dużych problemów, żeby intuicyjnie oszacować czy gdzieś null się pojawi. A jeśli się mylę to przeważnie jest jakiś gruby błąd projektowy i sedno jest dużo głębiej, a null tylko objawem. Być może tutaj jest kluczowy fakt, że dość długo już siedzę w jednym projekcie i trochę mi to zaciemnia obraz, a być może dlatego że już mam trochę doświadczenia i
  • Odpowiedz
@sakfa: No faktem jest, że ten optional wymusza pewien bezpieczniejszy styl kodowania i to muszę przyznać. Napewno praca z juniorami jest lżejsza wtedy. Z szerszej perspektywy jest to bardziej pożyteczne, acz patrzyłem pierwotnie bardzie ze swojej.
  • Odpowiedz