Czysty kod - szerszy opis kilku drobnych zasad

Jakiś czas temu, dałem do review swój kod programiście, który był znacznie bardziej doświadczony ode mnie. Programował już kilka lat, a ja dopiero kilka miesięcy. Dlatego ja stawiałem swoje kroki,  dość niepewnie jeszcze. Ale miałem coś, co jak się potem okazało, było dużym moim atutem, a mianowicie - robiłem to, co mi mówili :)

W tym przypadku, to, co mówili ci z największym autorytetem i doświadczeniem, bo gdy słuchałem różnych opinii na podane niżej tematy, to często każdy miał własne zdanie, i nie potrafił go poprzeć niczym ponad swoje długie doświadczenie.

Ale przecież jak ktoś ma 5 lat doświadczenia w robieniu tego samego w błędny sposób, to nie znaczy, że ten sposób jest lepszy od tego, co ktoś by robił to samo przez miesiąc, ale w poprawny sposób.

Dlatego wiedziałem, że potrzebuję jakiegoś solidnego fundamentu, jakiegoś autorytetu, o którego mógłbym się oprzeć. Nawet jeśli moje rozumowanie byłoby błędne, to przynajmniej nie myliłbym się sam, tylko razem z kimś, kto się bardzo dobrze zna, a to zawsze plus :)

Po sytuacji, którą za chwilę opiszę zacząłem obserwować, że stanowisko tego mojego kolegi, który oceniał moją pracę, nie jest oderwane od rzeczywistości ogółu doświadczonych programistów, dlatego jak będę pisał do kolegi, to możesz wyobrażać sobie, że będę pisał do ludzi, którzy po prostu mają odmienne zdanie :)

No dobra, nie przeciągam tego jakże długiego wstępu i już przytaczam to, co chciałem:

Pytanie:
Mój kolega napisał mi, że:

  1. nazwy moich metod, są za długie, powinny mieć 3-5 słów max,
  2. nazwy moich metod powinny być o jeden poziom abstrakcji wyżej (wcześniej mu to napisałem, ale on znowu mi zarzucił, że u mnie tak nie jest)
  3. nazwy metod nie powinny mówić wprost co robią, 
  4. zamiast długiej nazwy, lepiej dać komentarz.

Moja Odpowiedź:
Rozumiem Twoje wątpliwości. W związku z naszą ostatnią rozmową, postanowiłem nieco szerzej wyjaśnić motywy, jakie stały, przy moim dobieraniu takich, a nie innych nazw.

Odniosę się kolejno do tego, co napisałeś:



1. "3-5 słów max".

Zgodne z opinią Roberta Martina ogólnoświatowego autorytetu wśród programistów, autora książki "Czysty kod" (s. 61): nazwa powinna być najkrótsza, ale -- nie ma -- limitu długości nazwy. - zrzut poniżej:


Ja opieram swoje przekonania na temat długości nazw na podstawie literatury polecanej przez najlepszych programistów. Nie napisałeś na jakiej podstawie Ty opierasz swoje przekonanie na temat długości nazw.



2. "Tak jak wcześniej pisałeś, że jeden poziom abstrakcji wyżej"

Nie jestem pewien jak Ty interpretujesz jeden poziom abstrakcji wyżej. Ja interpretuję tak, jak wyczytałem we wspomnianej książce "Czysty kod" (s. 315) - Zrzut poniżej.



Czyli przykładowo, jeśli mam metodę, która rzuca wyjątek w sytuacji, gdy pole daty jest puste, to ten sam poziom poziom abstrakcji będzie np: "throwIfDateEmpty".
Jeśli natomiast chciałbym nadać nazwę o jeden poziom abstrakcji wyżej (uogólnić), to by było np. (checkDateExist).



3. "a nazwa metody nie jest do opisywania co metoda robi, znaczy jest, ale nie tak szczegółowo"

Nie wiem skąd masz takie przekonanie. Robert Martin w "Czystym Kodzie" twierdzi co innego (s. 40) - zrzut niżej.




4. "Zamiast pisać długie nazwy, lepiej napisać komentarz, co ta metoda robi"

    Co do Twojego przekonania o komentarzach z naszej ostatniej rozmowy, możesz o nich poczytać na stronie 75 "Czystego Kodu". Fragment zamieszczam niżej.





    Taką to ciekawą rozmowę odbyłem z moim kolegą dotyczącą nazw metod. Może jeszcze kiedyś napiszę o drugiej ciekawej rozmowie dotyczącej długości metod i klas, bo też była całkiem interesująca jak dla mnie i równie przydatna dla innych, jak ta powyżej.


Bardzo mnie interesuje co o tym sądzisz, dlatego byłoby mi miło, jeśli byś napisał w komentarzu coś o tym, może być cokolwiek :)

Komentarze

Popularne posty z tego bloga

IntelliJ: zmiana rozmiaru czcionki scrollem

ThunderBird: jak zrobić professional stopkę