Clean Code: funcții scurte și parametri

Clean Code: funcții scurte și parametri

Într-o discuție pe forum a venit vorba despre funcții scurte: cât de scurte ar trebui sa fie de fapt, cine stabilește ordinea asta și câți parametri ar trebui să aibă.

Argumentele sunt multe, dar se întâlnesc toate în același loc: codul este citit de mai multe ori decât e scris, ergo este important să poată fi urmărit cât mai bine.

Funcții mai scurte

Nu există un hard limit când vine vorba de lungimea funcțiilor, dar Uncle Bob zicea:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

Uncle Bob – Clean Code

Prin urmare, dacă poți sparge logica dintr-o metodă, fă-o. Folosește map și filter în loc de for, extrage condițiile în metode separate etc.

Motivele sunt simple: în timp ce citești o funcție, o și „execuți” mental. Deci, cu cât e mai lungă, cu atât e mai greu de „executat”.

De exemplu avem o condiție de forma asta:

if( user.role == 'customer' && user.orders.length && user.orders.indexOf(order.id) !== -1 ) { 
  //afișează comanda
}

Cât timp durează până îți dai seama ce se verifică în acel if? Dar dacă extragem toată condiția într-o funcție separată de forma de mai jos, cât timp ți-ai trebui?

if( userHasOrder(order.id) ) {
  //afișează comanda
}

Sigur, avem aceeași logică, dar nu vom încerca să parsăm mental ce se întâmplă acolo de fiecare dată când citim. Știm că evaluează true dacă utilizatorul are o comandă și aia e.

Evident, poți avea anumite excepții, mai ales dacă ai o metodă dumb. Mie mi se mai întâmplă să am un array cu 40-50+ elemente, dar metoda se ocupă doar acel array și nimic altceva. Nu are logică, nu are loop-uri, nu are nimic. Dar scopul e să limitezi lungimea.

Dar regula ce încerc să o urmez este: să intre pe maximum un ecran de-al meu (cu setările mele asta înseamnă ~30 linii). De cele mai multe ori îmi iese.

E valabil și pentru alte blocuri: interiorul condițiilor, switch/case, iterații de orice fel șamd.

Cât mai puțini parametri

În mod ideal, o funcție are zero parametri. Dar, cel puțin în limbajele „mele” (PHP în mod deosebit), treaba asta tinde spre imposibil (mai ales dacă este non OOP). Prin urmare, încerc să limitez cât mai mult, iar limita mea este pe la 3-4 parametri.

Dacă este nevoie de mai mulți, este un semn semnal destul de puternic că funcția respectivă face mai multe lucruri decât ar trebui și că ar fi rost de un mic refactor.

Un alt motiv pentru care numărul parametrilor trebuie să rămână mic este că, atunci când scrii codul, nu vei ști niciodată pe de rost în ce ordine se pune ce parametru. Și dacă nu folosești un IDE capabil să-ți ofere sugestii instant, pierzi timp (și focus!) schimbând între fișiere.

Dacă o metodă chiar are nevoie de mai mult de 3-4 parametri, eu prefer să îi trimit ca un array multidimensional (sau obiect, în JS), urmând să le dau default-uri dacă este cazul.

Abordarea asta are anumite dezavantaje (e.g. renunț la sugestiile editorului) dar vine cu posibilități de configurare on the fly. De exemplu, WP_Query acceptă un array, astfel încât pot configura query-ul în funcție de… chestii:

$args = [
  'post_type' => 'product'
];

if (isset($_GET['product-color'])){
  $args['meta_query'] = []; // configurează meta_query
}

$query = new WP_Query($args);

Fii flexibil!

Insist pe ideea că aceste limite sunt auto-impuse și, mai important, sunt arbitrare. Este important să nu te blochezi pe o idee (gen „omg, funcția mea are nevoie de 5 parametri și are 49 linii!”) ci să analizezi dacă poți simplifica lucrurile fără a exagera.

Este cel puțin la fel de important să nu aplici dogmatic regulile astea. Să analizezi cum este OK, să te consulți cu cei din echipa cu care lucrezi șamd.

Pentru că da, poți să o dai ușor în extrema cealaltă, să produci cod over engineered, unde extragi fiecare linie de cod doar pentru că a zis-o unu’ pe un blog :D

Un Comentariu

Adaugă un comentariurăspuns pentru

Poți adăuga bucăți de cod folosind [code]codul tău aici[/code], [js][/js], [php][/php] etc.

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Acest sit folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter