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.”

[
  • 93
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: Ta książka trochę przesadza w drugą stronę. W jaki sposób zwrócisz błąd wykonania (alternatywa dla nulla)?

Wyjątek? Jeszcze więcej kodu do złapania i zwijanie stosu.

Optional? Pole w obiekcie? Nadal potrzebujesz
  • Odpowiedz
@FEAofTruss: Czytam sobie ten czalendż od jakiegoś czasu i mam wrażenie że takie lakoniczne zdania wyrwane z kontekstu są bardziej szkodliwe niż pożyteczne. Przydałoby się jakieś podbudowanie tego zdania komentarzem. W obecnej formie nie rozumiem o co chodzi i po co to komu. (,)
  • Odpowiedz
@FEAofTruss swoją drogą należy według mnie rozróżniać wyjątki od błędów Wyjątek- sytuację wyjątkowe jak brak internetu, brak połączenia z bazą itp i je obsługiwać normalnie Exceptionami Błędy - normalne sytuacje takie brak użytkownika, niedozwolona akcja itp i je już powinno według mnie się obsługiwać normalnie z poziomu kodu a nie jakieś magiczne goto w postaci wyjątku. Pomocne tu są chociażby Either z vavra
  • Odpowiedz
@nilphilus nie chodzi mi o sytuację jak mówisz że jeden moduł pobiera sobie z drugiego coś (tak jak mowisz) tylko o to gdzie z obiektu dobierasz do obiektu gdzie dobierasz się do obiektu na którym potem coś robisz, jeśli te gety nie są jakimiś operacjami biznesowymi, a tylko getterami na pola
  • Odpowiedz
@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 ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@FEAofTruss: Ciężko z tym dyskutować ( ͡º ͜ʖ͡º) Mogę ewentualnie dodać, że powinny też mieć jak najmniejszy zasięg czyli odpowiedni scope aby w momencie gdy nie były nam już potrzebne, miejsce w pamięci zostało automatycznie zwolnione. ({}).
  • Odpowiedz
większość zmiennych zadeklarowałem na początku w grupach ze względu na przeznaczenie.


@Mr_NiceGuy: Brzmi jak dużo zmiennych czyli dużo kodu, czyli kod robi dużo rzeczy. Obstawiam, że w ogóle nie powinieneś mieć takiej potrzeby, gdyby ten kawałek kodu nie robił zbyt dużo rzeczy.
  • Odpowiedz
14/100 dni z książką

“Niewiele jest praktyk tak nieprofesjonalnych, jak zakomentowanie kodu: Nie rób tego!

InputStreamResponse = response = new InputStreamResponse();
response.setBody(formatter.getResultStream(), formatter.getByteCount());
  • 24
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: Komentowanie kodu doskonale sprawdza się jako narzędzie szybkiego debugowania w niektórych środowiskach. Czasem też chcesz wprowadzić tymczasowe zmiany lokalnie i zachować sobie stary kod, wtedy też szybki Ctrl+Shift+C są niezastąpione ( ͡º ͜ʖ͡º)
  • Odpowiedz
13/100 dni z książką

/*Dodane przez Ricka*/
Systemy kontroli wersji świetnie nadają się do zapamiętywania, kto (i kiedy) dodał określony fragment. Nie ma potrzeby zaśmiecania kodu tymi małymi dopiskami. Można uważać, że tego typu komentarze będę przydatne do sprawdzenia, z kim można porozmawiać na temat danego fragmentu kodu. Rzeczywistość jest inna - zwykle zostają tam przez lata, tracąc na dokładności i użyteczności.”
  • 11
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

12/100 dni z książką

“W wielu przypadkach kod mógłby zupełnie obejść się bez komentarzy [...] Co wolelibyśmy zobaczyć? To:

if((employee.flags & HOURLY_FLAG) && (employee.age > 65))
czy to:
  • 30
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: A mi się wydaje, że to:

if((employee.flags & HOURLY_FLAG) && (employee.age > 65))

może być ciałem metody employee.isEligibleForFullBenefits()

Można też nie bawić się w takie rzeczy, że klasa employee która przechowuje zapewne informacje o pracownikach jest odpowiedzialna też za sprawdzanie ich, a napisać zgrabny interfejs który będzie się zajmował takimi rzeczami ( ͡º ͜ʖ͡º)
  • Odpowiedz
11/100 dni z książką


“Nie komentuj złego kodu - popraw go. (Brian W. Kernighan i P.J. Plaugher)”

  • 21
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

10/100 dni z książką

“Funkcje powinny coś wykonywać lub odpowiadać na jakieś pytanie, ale nie powinny robić tych dwóch operacji jednocześnie. [...] Jako przykład weźmy następującą funkcję:

Public boolean set(String attribute, String value);
Lepszym rozwiązaniem jest oddzielenie polecenia od zapytania, dzięki czemu niejasność nie występuje:
  • 23
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@nilphilus: Jesli nawet nie do bazy to i tak przykład jest słaby
Coś jak:
if(zmienna == true ) zmienna = false;

jest masa funkcji które coś robią i coś zwracają i nie uważam że to nie jest
  • Odpowiedz
jest masa funkcji które coś robią i coś zwracają i nie uważam że to nie jest czytelne.

@zibizz1: gdyby tu tylko chodziło o to czy coś jest czytelne czy nie :) Ponadto CQRS, to może być ciekawa lektura.
  • Odpowiedz
9/100 dni z książką

“Idealną liczbą argumentów dla funkcji jest zero (funkcja bezargumentowa). [...] Należy unikać konstruowania funkcji o trzech argumentach. [...] Więcej niż trzy argumenty wymagają specjalnego uzasadnienia - a nawet wtedy takie funkcje nie powinny być stosowane”


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev
  • 25
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@AnonimoweLwiatko: bo im więcej argumentów tym więcej zależności. Chociaż ja bym nie powiedział że 0 to idealna liczba, bo skads przecież dane trzeba mieć. Oczywiście pomaga DI i korzystanie z tego co wstrzyknieto ale jednak. No ale już co do 3 to się zgadzam, lepiej unikać. No i unikac bool w argumentach bo to prawie na 100% oznacza że w środku jest if który zmusza funkcje do dzialania zupełnie inaczej
  • Odpowiedz
8/100 dni z książką

“Warto zapamiętać zasadę Warda: Wiemy, że pracujemy na czystym kodzie, jeżeli każda procedura okazuje się taką, jakiej się spodziewaliśmy. Połową sukcesu w osiągnięciu tego stanu jest wybór dobrych nazw dla małych funkcji wykonujących jedną operację. Im mniejsze i lepiej ukierunkowane są funkcje, tym łatwiej wybrać dla nich opisową nazwę.”


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev
  • 2
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

7/100 dni z książką

“Funkcje nie powinny mieć 100 wierszy długości. Funkcje powinny mieć właśnie nie więcej niż 20 wierszy.
[...]
Poziom wcięć w funkcji nie powinien przekraczać dwóch.
[...]
  • 13
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: Dodałbym jeszcze, funkcje powinny być testowalne. Dobrze od razu pomyśleć jak będzie wyglądał unit test. Właśnie pisząc testy czesto też dzieli się funkcje na mniejsze.
  • Odpowiedz
FUNKCJE POWINNY WYKONYWAĆ JEDNĄ OPERACJĘ. POWINNY ROBIĆ TO DOBRZE. POWINNY ROBIĆ TYLKO TO.”


@FEAofTruss: W skrócie SRP.

Jednak jest jedno "ale". W uproszczeniu powiem, że skoro funkcja ma 20 linii, to znaczy, że wykonuje 20 rzeczy (trzeba odliczyć nawiasy itp, ale upraszczam). To powoduje często błędne zrozumienie SRP i przesadzone rozdrobnienie kodu.
Więc jak ma robić jedną? Otóż brakuje tutaj pojęcia poziomu abstrakcji. Funkcja (lub ogólnie również klasa, metoda, pakiet
  • Odpowiedz
6/100 dni z książką

“Ludzie często nie zmieniają nazw elementów z obawy, że inni programiści będą mieli zastrzeżenia. [...] Prawdopodobnie zaskoczymy kogoś, gdy zmienimy nazwę, podobnie jak w przypadku innych usprawnień kodu, ale nie powstrzymuje to nas przed dokonywaniem zmian.”


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev
  • 4
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@FEAofTruss: A teraz wyobraź sobie, że każdy zacznie zmieniać nazwy na jego zdaniem "bardziej pasujące". Kod będzie zmieniany w tą i w tamtą aż do posrania i wszystkie MD polecą na refaktoring :)
  • Odpowiedz
@FEAofTruss: @chopak: zmienianie nazw modułów czy jakichś podstawowych klas oczywiście stworzy bałagan i tego lepiej nie robić.
Ale poprawianie np. zmiennych które są widoczne w jednym miejscu jak najbardziej jest ok. W większych projektach wiele klas ruszanych jest nawet raz na kilka miesięcy, więc po zmianie nazwy zmiennej nikt nie będzie tym później zaskoczony bo i tak nie będzie pamiętał co tam było, ani nie będzie co chwila
  • Odpowiedz
5/100 dni z książką


“W hipotetycznej aplikacji o nazwie Luksusowa stacja benzynowa nie należy prefiksować każdej klasy skrótem LSB. Po prostu będziemy mieli przeciwko sobie używane narzędzia. Wpisujemy L, naciskamy klawisz dokańczania i otrzymujemy długą na kilometr listę wszystkich klas w systemie.”
  • 3
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

4/100 dni z książką

“Gdy konstruktory są przeciążone, należy używać metod fabryk o nazwach opisujących argumenty. Na przykład:

Complex fulcrumPoint = Complex.FromRealNumber(23.0);
Jest zwykle lepsze od:
  • 27
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

3/100 dni z książką

“Osobiście pozostawiam nazwy interfejsów bez dekoracji. Początkowe I, tak częste w istniejącej bazie kodu, jest w najlepszym przypadku zakłóceniem, a w najgorszym nośnikiem zbyt dużej ilości informacji. Nie chcę, aby moi użytkownicy wiedzieli, że przekazuję im interfejs.”


#feaoftruss #czystykod #programowanie #programista15k #webdev #gamedev
  • 7
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

via Wykop Mobilny (Android)
  • 4
@FEAofTruss: nie rozumiem, przecież użytkownik powinien wiedzieć że ma do czynienia z interfejsem a nie np klasą abstrakcyjną. Możesz mi to wyjaśnić?
  • Odpowiedz
@kovalski: Otóż nie.

Dla Ciebie jako użytkownika interfejsu jest bardzo wszystko jedno, co dostaniesz pod spodem. To, co Ciebie interesuje to fakt, że rzecz, którą dostajesz wyraża pewne zachowanie.

Na przykład:
Jeżeli masz interfejs Printable z metodą print() to Tobie obojętne jakiego typu obiekty do Ciebie przychodzą. Mogą przyjść PDFy, obrazki, pasta o serwerowni. Tak długo jak każdy z tych obiektów obsługuje Printable to będzie traktowany kompletnie jednakowo.
  • Odpowiedz