Wszystko

Najnowsze

Archiwum

FEAofTruss
  • 9
22/100 dni z książką

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
  • 17
  • Odpowiedz

  • Otrzymuj powiadomienia
    o nowych komentarzach
FEAofTruss
  • 19
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
Vetinari
  • 7
@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
SiarczekPotasu
SiarczekPotasu
  • 11
@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
krasnoludkolo
  • 4
@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
krasnoludkolo
  • 1
@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
dotnetboy
dotnetboy
  • 3
@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
AnonimoweLwiatko
  • 14
@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
zakopiak
zakopiak
  • 8
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
FEAofTruss
  • 57
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
AnonimoweLwiatko
  • 17
@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
FEAofTruss
  • 67
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
FEAofTruss
  • 116
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
AnonimoweLwiatko
  • 28
@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
FEAofTruss
  • 43
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
FEAofTruss
  • 47
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
zibizz1
zibizz1
  • 7
@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
kawal_leszcza
kawal_leszcza
  • 2
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
FEAofTruss
  • 34
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
nilphilus
nilphilus
  • 5
@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
FEAofTruss
  • 47
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
FEAofTruss
  • 59
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
Kierman
  • 9
@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
zakopiak
zakopiak
  • 14
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
FEAofTruss
  • 22
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
chopak
chopak
  • 1
@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
asciiterror
  • 3
@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
FEAofTruss
  • 23
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
FEAofTruss
  • 15
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
FEAofTruss
  • 11
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
kovalski
kovalski
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
SwordPL
SwordPL
  • 1
@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

Powiązane tagi