Care este mare lucru cu denumirea? Și de ce ar trebui să ne pese de asta? Este doar un nume.
Numirea variabilelor, metodelor, claselor, pachetelor etc sunt adesea acordate mai puțină îngrijire decât merită. Foarte des întâlnim nume precum i,j,k sau nume fără sens precum customerServicingProfileObjectUtil. Nu credem că este important să ne luăm câteva minute pentru a găsi nume mai bune pentru componentele programului nostru. La urma urmei, este doar un nume. Dacă nu înțelegem ce face, putem întotdeauna să citim codul și să-l dăm seama.
Numirea poate însemna mai mult decât credem că înseamnă. Dacă nu reușim să venim cu un nume bun pentru o componentă, aceasta ar putea însemna oricare dintre următoarele
- Nu înțelegem responsabilitățile acelei componente
- Are mai mult de o responsabilitate
Deci, venind cu un nume bun, putem vedea problemele în mod clar și refactoriza codul pentru a curăța mai bine codul. De asemenea, ajută la lizibilitatea codului nostru. Dacă vedem o metodă cu un nume care dezvăluie intenția, nu trebuie să cercetăm metoda respectivă încercând să ne dăm seama ce face, astfel încât înțelegerea codului este mai rapidă. La urma urmei, scriem codul pentru a-i face pe alți oameni să-l înțeleagă.
Un alt miros de cod prost este atunci când trebuie să folosim comentarii pentru a descrie o componentă în loc să-i folosim numele. În schimb, putem redenumi pur și simplu componenta cu un nume semnificativ, astfel încât să evităm necesitatea acelui comentariu.
Exemplu de la Robert C Marting în cartea sa de coduri curate:
În loc de int d; // elapsed time in days folosiți int elapsedTimeInDays
Când numim corect componentele, le înțelegem mai bine, ne dăm seama că pot aparține unor locuri diferite. Practic, refactorăm mai bine codul.
