Readability Matters More Than Correctness

Un argument foarte bine prezentat în favoarea unui cod citeț într-o dezbatere citeț vs funcțional.

https://xph.us/2017/04/23/readability.html

6 Likes

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

― Martin Fowler

9 Likes

Totusi, programatorii inteleg mai multe decat un om oarecare. Anumite “scurtaturi” sunt binevenite si luate ca miscari inteligente de alti dezvoltatori.

In limbajul Go au facut o chestie foarte faina. Au simplificat foarte mult limbajul si l-au redus la un set de operatii simple. Apoi dupa o formatare standard a textului rezulta un cod care poate fi citit de orice programator incepator sau avansat. Practic e aproape imposibil sa scrii un cod incalcit sau neinteligibil. Intr-un fel e foarte ok asa, compilatoarele actuale sunt asa de destepte incat e cam greu sa mai faci tu optimizari prin cod mai bune decat ele.

2 Likes

Un raspuns primit de Keith Rarick pe twitter, e mult mai aproape de ce se intampla de obicei

I’ve never had to throw out code because it’s hard to read. But I have thrown out code because it was broken.

1 Like

Eu merg pe readibility, un code clean code este mai bug free decat unul mess.

3 Likes

Până la urmă contează să ai metode scurte. Dacă depăsește un ecran, scrii o metodă privata care face ceva, chit că e folosit doar o singură dată. E mai ușor să înțelegi un

this->calculateData();

decât 10 linii de adunări și înmulțiri.

Ba ăsta e unul dintre cele două motive pentru care arunci cod (celălalt fiind că nu mai ai nevoie de acel cod).

De exemplu, dacă ai un calculator care în loc de adunare face înmulțire, de ce ai șterge tot codul și ai scrie de la zero? Pentru că nu face operația bine sau pentru că nu-ți dai seama de ce face operația greșit?

2 Likes

Exagerezi :slight_smile:
Ar trebui sa fiu mult prea plictisit (sau beat) ca sa arunc cod functional doar pentru ca mi se pare mie greu de citit. In schimb l-as arunca fara nici o ezitare daca ar fi fubar, indiferent de cat de “citet” ar fi

Din punctul meu de vedere nu exista o asemenea dezbatere, eventual functional vs functional si citet

stiluri de programare :slight_smile:

6 Likes

Asta cum suna?

3 Likes

Din experienta mea de pana acum, cele mai mari probleme le-am avut cu codul care e “ermetic” pt ca vrea sa ne arate cat e de indemanatic cineva in limbajul de programare/frameworkul respectiv. de obicei aceasta metoda o folosesc cei care doresc sa se faca indispensabili tocmai din aceasta ermeticitate, si nu din valoarea pe care o adauga ca si programatori indemanatici.

Codul cel mai bun este cel portabil intre diversele limbaje de programare. Abia atunci se vede maturitatea autorului, din faptul ca viitori colegi cu background divers pot prelua munca lui/ei si dezvolta peste (sau s-o intretina).

7 Likes

Ar mai trebui mentionat ca o alta caracteristica a unui proiect prost (care se poate incadra la readability) este documentarea deficitara sau multa si aiurea. Nu de putine ori am vazut proiecte care desi au o documentare vasta nu intelegi aproape nimic din ea. Au fost situatii incredibile in care efectiv nu am reusit sa inteleg ce facea de fapt un intreg proiect :unamused:
Personal prefer ca orice proiect (sa fie) documentat (si) sa inceapa cu o descriere clara a ce face acel proiect si cum se foloseste sau cum se integreaza codul ala cu altul. Abia dupa aia sa zicem ca ne uitam la cod.

“Any fool can write comments that nobody can understand. Good programmers write documentations that humans can understand.”

― Martin Fowler (modified by me) :slight_smile:

Ca de obicei, intre alb si negru sunt o gramada de nuante de gri. Codul “ermetic” de dragul de a fi ermetic nu e ok, asa cum nu e neaparat ok (din punctul meu de vedere) sa scrii 3 ecrane de prostii cand totul se poate face in 5 linii, si asta ca sa nu se simta lezat niciun “programator Wordpress” :slight_smile:

Asta pentru că documentarea nu are legătură directă cu codul respectiv, adică nu este un “living documentation” adică nu s-a efectuat o dezvoltare condusă de teste(bdd/tdd) și asta pentru că nu a fost făcută nici o sesiune de design(impact mapping, example mapping, event storming, etc ) înainte ca echipa/omul orchestră să afle despre ce anume este important și valoros în domeniul respectiv, care este flow-ul din acel domeniu, și doar i s-a predat o soluție și i s-a impus și un deadline, așa că a facut fiecare ce poate mai bine și asta e, dar dacă încă nu a murit proiectul respectiv probabil ceva mai încolo vor chema un consultant să le spună ce anume nu este în regulă cu proiectul lor :slight_smile:

Intai corect, cred eu. Care exprima intentia cu claritate. Altfel seamana mai mult a caligrafie.
De obicei merg mana in mana. Rare cazurile in care un cod ilizibil e corect.
Mai este si cazul de ilizibilitate prin volum. Nu face mare lucru, dar se intinde pe zeci de pagini. Il rescriem mai sintetic. Si corect. Acum e juma’ de pagina. Simplu, dar ilizibil prin taria abstractiei (trebe descifrat pe hartie inainte).

1 Like