Ciemna noc, amerykański samolot wojskowy leci na akcję. Cel: zrzucić spadochroniarzy na wyznaczony obszar na terytorium wroga. Samolot zatoczył krąg, zapala się czerwona lampka, a następnie zielona. Grupa komandosów wyskoczyła nad celem.
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
@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 z-----e.
Za górami, za lasami żył Bin Laden z talibami, aż pewnego dnia we wtorek, gdy dopisał mu humorek, zamiast SHIFTu wcisnął ENTER, i r------ł World Trade Center.
@FEAofTruss: Całkowicie się nie zgadzam. Nulle są często wskazane na froncie. Są często sytuacje na froncie kiedy celowo chcesz ustawić coś na null zamiast undefined.
@FEAofTruss: Chyba pierwsza faktycznie jakąś madrzejsza i mniej oczywista rzecz. Zawsze programuj do abstrakcji. Jak pierwszy raz pracowałem w korpo byłem zaskoczony ile tam interfejsów ( ͡°͜ʖ͡°)
“A zatem powinniśmy tworzyć krótkie wiersze. Stare ograniczenie Holleritha do 80 znaków jest restrykcyjne [...] Ja staram się nie przekraczać długości 120 znaków.”