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
@krasnoludkolo: @ZasilaczKomputerowy:
Narzuca styl kodowania, ale też wydajność nie jest wcale gorsza o 0.001% jak napisałeś, bo chyba nie masz wyobrażenia jak to działa wewnątrz.

Po pierwsze wątpię czy obiekt i optional do niego mają "spatial locality" (nie wiem jak to jest po polsku).

Po drugie do każdego optionala musisz i tak zrobić if, który wywoła metodę (może będzie zoptymalizowana do odczytania pola, a może nie), a potem pobrać zawartość
  • Odpowiedz
Jeżeli piszesz lekki serwer, który pobiera wartość z redisa/bazy/whatever, opakowuje w optional i zwraca go przez HTTPS albo zwraca error code response (czyli musi mieć ifa) to większość kodu w metodzie będzie oparta na optional i załóżmy 1.5x wolniejsza niż null check.


@Vetinari: Chciałbym zobaczyć benchmark.

99% czasu ta aplikacja spędzi na komunikacji z bazą, ale ok powiedzmy że CPU się wtedy nudzi.

Pozostały 1% który faktycznie zużywa CPU to będzie
  • Odpowiedz