ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 142
Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 26
Abonament PDF

Clean Code - Naming

Radu Vunvulea
Solution Architect
@iQuest



PROGRAMARE


Dacă eşti un programator cu experiență atunci ai auzit de cartea „Clean code” scrisă de Robert C. Martin. În multe companii, această carte a devenit parte din biblia dezvoltatorului. Combinată cu „Clean Coder” (Programatorul Curat), aş spune că aceste două cărţi sunt obligatorii pentru toţi dezvoltatorii.

Voi realiza o serie dedicate acestui subiect. Dacă deja aţi citit cartea, atunci este o ocazie bună să vă o reactualizați. Pentru ceilalţi, acesta este momentul perfect pentru a descoperi cât de bine ar trebui să arate codul. Toate ideile principale sunt preluate din „Clean Code” (Cod Curat). Puteţi privi această serie de articole drept un rezumat al cărţii în sine.

De ce?

Am decis să încep să scriu despre această temă deoarece sunt lucruri care trebuie reamintite şi recapitulate din când în când. „Clean Code” este genul de carte pe care nu o citeşti doar o dată şi apoi o arunci într-un colţ întunecat al camerei tale. Este genul de carte pe care o reciteşti iar şi iar. De fiecare dată vei descoperi lucruri noi pe care le-ai omis sau care sunt revelatoare pentru tine în mai multe feluri.

Denumirea

Acesta este primul subiect pe care îl vom dezbate în acest articol. Un nume bun poate înlocui o documentaţie de o pagină şi poate ajuta un alt dezvoltator să înţeleagă aplicaţia şi să găsească o problemă într-o perioadă mai scurtă de timp. Totul într-o aplicaţie are un nume, de la un field (câmp) banal la numele unei metode sau al unei componente. De aceea este important să dai şi să utilizezi denumiri potrivite.

De câte ori v-aţi uitat peste un cod scris cu trei luni în urmă şi nu v-aţi putut aminti ce aţi făcut acolo? De aceea, o denumire bună este de neînlocuit.

Denumirile trebuie să dezvăluie intenţia ta

Un nume bun poate să îţi economisească 10 minute de debugging (depanare) sau 20 de minute de căutare prin documentaţie. Atunci când ne uităm peste un cod, acesta trebuie să se desfășoare în mod coerent. Chiar şi cel mai complex algoritm ar trebui să fie uşor de citit dacă ai o denumire bună.

Numele unui câmp, metodă, clasă sau componentă ar trebui să ne spună de ce a fost creat(ă), care este scopul său principal. Mai jos puteţi găsi exemplul clasic care este dat atunci când vorbim despre acest subiect.

DateTime d;
DateTime dn;
DateTime dlr;

Dacă ne uităm peste aceste definiţii ale câmpurilor sau dacă le vedem undeva în codul nostru, nu am avea nicio idee despre ceea ce reprezintă aceste câmpuri sau de ce au fost ele utilizate (create).

DateTime creatingDate;
DateTime currentDate;
DateTime timeFromLastRun;

Denumirile de mai sus ne oferă mai multe informaţii despre câmpurile noastre. Ne este clar care este scopul fiecărui câmp şi ce fel de informaţii ne oferă.

Nu ar trebui niciodată să folosim o denumire sofisticată sau care ascunde scopul unei resurse anume. Nu uitaţi că un nume lung nu afectează performanţa aplicaţiei. Da, este adevărat că în anumite limbaje aceasta poate să mărească dimensiunea aplicaţiei, dar în zilele noastre spaţiul nu mai este o problemă – este mai scump să ai o echipă de suport care nu înţelege o parte a aplicaţiei.

Evitaţi dezinformarea

Găsirea unui nume bun poate dura ceva timp, dar ne poate economisi timp mai târziu. Deoarece găsirea unor denumiri bune este destul de dificilă, este destul de uşor să recurgi la nume care sunt deja consacrate. De exemplu, utilizarea numelor ca „hp”, „cmd” sau „sco” este dăunătoare. Acestea sunt nume care sunt deja utilizate drept comenzi de către sistemul de operare.

Atunci când alegi un nume care este deja utilizat în alt context ar trebui să ai grijă să îl utilizezi în acelaşi context sau cu acelaşi sens. Nu utilizaţi niciodată denumiri consacrate în alte scopuri.

carList
houseList

Ce observați în exemplele de mai sus? Sufixul „List” ne spune că variabila este o colecţie de maşini sau case. Dacă variabila reprezintă numai o maşină sau o casă, atunci numele induce în eroare. De asemenea, există cazuri în care „List” este utilizat chiar dacă desemnează o mulţime sau alte tipuri de colecţii.

Un alt aspect important este denumirea similară a câmpurilor. În exemplele de mai jos avem două câmpuri care sunt diferite numai printr-o singură literă, sau alte două câmpuri care sunt foarte lungi, iar observarea diferenţei este dificilă.

cars
car
optimizelViewConfigurationUsingAVirtualProcess
optimizeIViewConfigurationUsingBVirtualProcess

În exemplul legat de „car(s)”, găsirea unei denumiri precum currentCar şi carCollection ne-ar putea ajuta să înţelegem scopul lor.

Evitaţi utilizarea caracterelor care sunt similare, cum ar fi „L” mic (l) şi „I” („i”) mare sau „0” (Zero) şi „O” („o” mare). Este extrem de dificil să observi diferenţa dintre ele. În exemplul de mai sus, cel legat de denumirile lungi, prima literă după „optimize” nu este aceeaşi.

Faceţi diferenţe cu înţeles

Într-o aplicaţie, se poate întâmpla să sfârşeşti prin a avea denumiri similare, chiar dacă ai încercat să faci o diferenţă clară între ele. Din această cauză se poate să scriem un cuvânt greşit sau să adăugăm numere la finalul unei denumiri.

În exemplul de mai jos avem o metodă care transformă un şir dintr-un format în altul.

void Convert(string s1, string s2)

Numele parametrilor de input (intrare) nu ne ajută să înţelegem logica. Înlocuirea lui s1 cu input sau inputInXYZFormat şi s2 cu output sau converted sau outputInABCFormat ne-ar ajuta mai mult.

Când nu avem idei pentru a denumi o clasă, putem sfârşi prin a avea 3 clase cu următoarele nume:

Car
CarData
CarInfo

Problema cu această denumire este că nu există o diferenţă clară între „Data” şi „Info”. Cititorul nu va şti ce fel de informaţie conţine fiecare clasă.

Utilizarea sufixelor sau a prefixelor care reprezintă tipul câmpului nu ne ajută să facem un cod mai lizibil. Care este diferenţa dintre „Name” şi „StringName” sau „NameString”? Nu este nicio diferenţă în final. Un nume precum „CarName” ar fi mai util. Acelaşi lucru este valabil şi pentru denumirea metodei, a proprietăţilor sau a clasei.

Utilizaţi nume uşor de pronunţat

Chiar dacă codul este scris pentru maşini (010101001), este destul de sigur că vei ajunge în timpul depanării sau a reutilizării să vorbeşti cu altă persoană despre acel cod. Ar suna destul de stupid să denumeşti un câmp într-un fel pe care nu îl poţi citi sau să foloseşti o denumire care este codată.

'carN4RegS1' – 'carNumberForRegistrationSection1'
'dtoCRcrd100' – 'car'

Folosiţi nume care pot fi căutate

Sună ciudat? Nu.

Tu ai nevoie să cauţi în cod pentru a vedea diferitele câmpuri utilizate. Da, este adevărat că noile IDE pot face treaba asta pentru noi, dar totuşi trebuie să folosim denumiri care pot fi căutate uşor.

De exemplu, cât de uşor este să găseşti unde a fost utilizat „i” sau „j”? Acelaşi lucru se întâmplă cu cuvintele magice care sunt folosite în linie, fără a le extrage drept constante.

De exemplu, căutarea şi înlocuirea unei valori numerice într-o aplicaţie poate fi un coşmar dacă aceeaşi valoare a fost utilizată în linie pentru cazuri de utilizare diferite.

Evitaţi codificarea

Nu încerca să reinventezi roata şi să-ţi defineşti propria codificare pentru lucruri care au fost deja definite şi standardizate. Ultimul lucru pe care doreşti să îl ai este propriul tău limbaj personalizat.

De aceea, încearcă să foloseşti prefixe precum „I” pentru interfeţe sau sufixul „Base” pentru clase abstracte. Nu folosi prefixul „C” pentru implementarea claselor sau „m_” pentru variabile.

Dacă sfârşeşti prin a avea o codare personalizată, fă un pas înapoi şi încearcă să vezi de ce ai ajuns în situaţia asta. În funcţie de acest răspuns, ar trebui să iei o hotărâre.

Evitaţi hărţile mintale

Să începem cu un exemplu:

r
t
p

Chiar dacă suntem dezvoltatori, nu dorim să învăţăm şi să memorăm că „r” înseamnă întregul url al Dacia server din România, „t” este acelaşi url, dar fără informaţia protocol şi „p” reprezintă parametrii de interogare pe care trebuie să îi trimitem la server pentru a putea să ne logăm.

Chiar dacă hărţile mintale nu sunt benefice, există câteva denumiri care sunt standard în zilele noastre. De exemplu, atunci când vedem un „i” sau „j”, ştim din primul moment că vorbim despre o iterare.

Denumirea Claselor şi a Metodelor

Există două reguli simple care ne pot ajuta mult atunci când trebuie să găsim un nume bun pentru clasa noastră sau pentru metode:

Încercaţi să evitaţi denumirea claselor cu prefixe sau sufixe precum Service, Factory, Processor, Data, Info. Aceste denumiri de clase sunt întrebuinţate prea mult (mai ales când nu găsim denumiri mai bune).

Alegeţi un cuvânt per concept

Un concept din sistemul tău ar trebui să aibă aceeaşi denumire. Fii consecvent în această privinţă. Nu vrei să ai două nume pentru o clasă care exprimă acelaşi concept. De exemplu „Processor” şi „Analyzer” sau „Controller” şi „Manager”.

Utilizarea aceluiaşi cuvânt per concept îi va ajuta pe dezvoltatori să înţeleagă codul mai uşor.

Utilizaţi denumiri din numele domeniu Soluţie şi Problemă

Nu folosiţi denumiri care sunt din afara contextului şi nu sunt din acel domeniu specific. Este mai natural pentru cineva care lucrează în industria auto să folosească cuvântul „motor” şi nu „sursă de putere”. Ar trebui să utilizaţi denumirile specifice ale domeniului şi nu alte denumiri date de dezvoltatori, care pot fi greşite.

Aceasta poate fi o cauză de neînţelegere între clienţi şi dezvoltatori.

Nu adăugaţi context nejustificat

Este destul de uşor să adaugi context lucrurilor care sunt deja clare. De exemplu, într-o clasă denumită „Car”, nu este nevoie să numeşti câmpul culoare al clasei „carColor” sau „colorCar”. Eşti deja în clasa maşină şi toate informaţiile din această clasă sunt legate de „Car (Maşină)”.

Concluzie

Găsirea denumirilor bune într-o aplicaţie poate fi o treabă dificilă şi care necesită mult timp. Nu este simplu să găseşti denumiri bune. Dar ar trebui să investiţi timp pentru a găsi şi utiliza denumiri potrivite.

Cuvinte de încheiere

Diferenţa dintre un programator deştept şi unul profesionist este că profesionistul înţelege importanţa clarităţii. Profesioniştii îşi folosesc abilităţile pentru a scrie cod care poate fi înţeles de către alţii.

Conferință

NUMĂRUL 142 - Robotics & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • P3 group
  • Ing Hubs
  • Colors in projects

INTERVIURI VIDEO