Rezumatul codului curat și punctele cheie - DZone DevOps
Cu mult timp în urmă, am folosit acest rezumat al unor puncte cheie pe care le-am subliniat pentru a studia cartea Clean Code. Sper că îi ajută pe ceilalți.
Alăturați-vă comunității DZone și obțineți experiența completă a membrilor.
Cu mult timp în urmă, am folosit acest rezumat al unor puncte cheie pe care le-am subliniat pentru a studia cartea Clean Code. Sper că îi ajută pe ceilalți. (Notă: acest rezumat nu exclude necesitatea de a citi cartea.)
Ce este codul curat?
Codul poate fi măsurat fie cu „bine”, fie cu „rău” în revizuirea codului sau cu câte minute îți ia să vorbești despre el.
Un cod curat trebuie să fie elegant, eficient, lizibil, simplu, fără duplicări și bine scris.
Ar trebui să adăugați valoare companiei cu codul dvs.
Codul curat oferă calitate și înțelegere atunci când deschidem o clasă.
Este necesar ca codul dvs. să fie curat și lizibil pentru ca oricine să îl găsească și să îl înțeleagă cu ușurință. Evitați să pierdeți timpul altora.
Nume semnificative
Numele claselor, variabilelor și metodelor trebuie să fie semnificative și să indice clar ce face o metodă sau ce este un atribut.
Creați nume pronunțabile pentru a facilita comunicarea.
Evitați acronimele și evitați denumirile confuze, ceea ce poate duce la concluzii greșite pe oricine citește codul.
Utilizați nume care reflectă domeniul sistemului, contextul și problemele care trebuie rezolvate.
Funcții
Metoda ar trebui să fie ușor de citit și de înțeles.
Metoda ar trebui să-și transmită intenția.
Metodele ar trebui să fie mici. O altă regulă pentru metodele mici este că acestea ar trebui să fie și mai mici.
Trebuie să aibă până la 20 de linii. (Cred că ar trebui să aibă până la 10 rânduri.)
Metodele ar trebui să facă un singur lucru: ar trebui să o facă în modul corect și să o facă.
Ar trebui să folosiți nume cu cuvinte care să spună ce face cu adevărat.
Numărul optim de parametri ai unei metode este zero, după unul și doi.
Trebuie evitate trei, dar dacă credeți că ar trebui să fie utilizate, aveți o bună justificare.
Parametrii de tip boolean ca parametru afirmă deja în mod clar că face mai multe lucruri.
Metodele trebuie să facă ceva și să returneze ceva.
Comentarii
Unul dintre cele mai frecvente motive pentru comentarii este că codul este rău.
Dacă vă gândiți să scrieți un comentariu, atunci codul ar trebui refactorizat.
Comentariile nu salvează un cod greșit.
Încercați să explicați ce face codul să se întâmple.
Comentariile pot fi utile atunci când sunt plasate în anumite locuri.
Creați nume de metode și variabile informative în loc să explicați codul cu comentarii.
Comentariile pot fi folosite pentru a exprima importanța anumitor puncte din cod.
Cel mai bun comentariu este unul care trebuie scris deoarece codul dvs. a fost deja explicat.
Nu scrieți comentarii cu informații redundante, inutile sau false.
Acestea nu ar trebui folosite pentru a indica cine s-a schimbat sau de ce, pentru că există deja în versiune.
Nu comentați codul care nu va fi utilizat, eliminați-l, ci doar poluează codul și nu lasă nicio îndoială în oricine citește.
Formatare
Formatarea ar trebui să indice lucruri importante, deoarece este un dezvoltator de forme de comunicare.
Un cod dezordonat este greu de citit.
Citibilitatea codului va intra în vigoare la toate modificările care vor fi făcute.
Încercați să scrieți o clasă cu maximum 500 de linii. Clasele mai mici sunt mai ușor de înțeles.
Setați o limită de caractere pentru fiecare linie de cod.
O limită bună de caractere pe o linie este 120.
Încercați să păstrați mai multe concepte legate în continuare pe verticală pentru a crea un flux de cod.
Folosiți spații între operatori, parametri și virgule.
Obiecte și structura datelor
Urmați Legea lui Demeter, care spune că o metodă M a unui obiect O poate consuma doar servicii din următoarele tipuri de obiecte:
- Obiectul în sine, Oh.
- M parametrii.
- Orice obiect creat sau instanțiat de M.
- Componente directe ale O.
Faceți o bună abstractizare și încapsulare.
Nu creați obiecte stupide.
Obiectele ascund abstractizarea datelor și expun metode care operează datele.
Structurile de date vă expun datele și nu au metode semnificative.
Eroare de manipulare
Tratarea erorilor trebuie planificată cu atenție de către toți programatorii.
Când se întâmplă lucruri greșite, trebuie să-l facem să facă lucrurile corecte.
Ar trebui să preferăm lansarea unei excepții decât tratarea ei doar pentru a ascunde.
Creați mesaje cu informații despre eroare.
Menționează că a eșuat. Unde a fost acest eșec? Dacă este posibil, menționați de ce a eșuat.
Consultați reguli comerciale separate pentru erori și gestionarea erorilor.
Evitați să returnați un NULL în metode, de preferință pentru a returna un obiect gol.
Evitați să treceți NULL la metode; acest lucru poate genera NullPointerExceptions.