Cinci obiceiuri bune la programarea pe php

La fel ca în cazul oricărui alt limbaj de programare, dezvoltatorii PHP pot scrie cod PHP de o calitate foarte diferită - de la complet îngrozitor la foarte bun. Aflați abilitățile unei bune programări care vă va ajuta să creșteți productivitatea.







Din punctul de vedere al productivității, un dezvoltator "excelent" poate depăși doar un dezvoltator "bun" de 10 până la 20 de ori. Un dezvoltator excelent este mai productiv datorită experienței sale și respectării obiceiurilor bune. Modelele de programare proaste care se strecoară în codul dvs. sunt cauza declinului productivității. Acest articol demonstrează câteva obiceiuri bune, a căror urmărire vă va ajuta să vă îmbunătățiți abilitățile profesionale ca programator.

Pe lângă îmbunătățirea productivității în procesul de scriere a codului, aceste obiceiuri vă vor ajuta să creați un cod de calitate proiectat pentru întreaga durată de viață a aplicației. Pentru orice cod pe care îl creați, cea mai mare parte a duratei de viață este probabil să fie în faza de întreținere, iar întreținerea aplicațiilor, de regulă, necesită cheltuieli mari. Respectarea obiceiurilor bune de codificare îmbunătățește performanța designului, inclusiv gradul de modularitate, făcând codul mai ușor de înțeles și, prin urmare, mai ușor și mai ieftin de întreținut.

Modelele obișnuite în domeniul codificării duc la apariția defectelor din codul programului și pot face ulterior dificilă modificarea acestuia fără apariția unor noi defecte. Următoarele cinci obiceiuri bune, aplicate în codul dvs. PHP, vă vor ajuta să evitați aceste capcane.

  1. Dați nume potrivite
  2. Păstrați codul în fragmente mai mici
  3. Documentează-ți codul
  4. Efectuați erori
  5. Nu utilizați niciodată operația "copiere și lipire"

Următoarele secțiuni sunt dedicate unei explicații detaliate a acestor obiceiuri.

Dați nume potrivite

Mod obișnuit: nume ambigue sau fără sens

Lista 1 prezintă un exemplu de cod care conține nume de variabile prea scurte, abrevieri complexe și nume de metode care nu descriu acțiunile pe care le efectuează. Denumirea metodei, sugerând orice acțiune efectuată de această metodă, în timp ce în realitate face ceva complet diferit, poate fi extrem de dăunătoare, deoarece va fi înșelătoare.

Lista 1. Obiceiul rău: nume ambigue sau fără sens

Obiceiul obișnuit: nume semnificative și concise

Codul din listare 2 demonstrează folosirea unor obiceiuri bune de desemnare. Numele de metode modificate reflectă mai bine ce fac aceste metode și de ce. Numele de variabile au devenit, de asemenea, mai semnificative. Singura variabilă care a rămas scurtă în această listă este variabila $ i. Deși mulți pot fi în dezacord cu mine, dar cred că numele scurt pentru variabila buclă este destul de acceptabil și chiar o alegere bună, deoarece indică clar scopul său funcțional.

Lista 2. Un obicei bun: nume semnificative și concise

Vă recomandăm să reprezentați un bloc condițional mare sub forma unei metode și să dați acestei metode un nume care descrie această condiție. Această tehnică simplifică citirea codului și pune condiția într-o formă externă, astfel încât să poată fi extrasă și, eventual, refolosită. Dacă se modifică formularea condiției, este mai ușor să actualizați metoda corespunzătoare. Deoarece această metodă are un nume semnificativ, codul nu își va pierde semnificația și nu va deveni dificil de citit.

Păstrați codul în fragmente mai mici

Este destul de ușor să vă concentrați asupra rezolvării problemei și să începeți să scrieți codul. Pe măsură ce rezolvăți sarcina curentă, funcțiile dvs. devin mai lungi și mai lungi. Aceasta nu este o problemă pe termen lung, dacă mai târziu vă întoarceți și reformați codul în formă de fragmente mai mici.

Ar trebui, de asemenea, să formați un obicei de a scrie metode, astfel încât fiecare să îndeplinească una și o singură funcție. Există mai multe motive pentru o astfel de atenție deosebită a metodelor de scriere. În primul rând, metoda este mai ușor de aplicat în mod repetat, dacă are doar un singur lucru și o face bine. În al doilea rând, astfel de metode sunt mai ușor de testat. În al treilea rând, astfel de metode sunt mai ușor de înțeles și mai ușor de schimbat dacă este necesar.







Mod obișnuit: funcții lungi (care fac prea mult)

Lista 3 prezintă un exemplu de funcție lungă. Această funcție reprezintă o sursă de probleme potențiale din mai multe motive. Ea efectuează multe acțiuni independente. Este greu de înțeles, de depanat și de testat. Ea iterează și construiește o listă de elemente, atribuie valori obiectelor, efectuează calcule etc.

Listing 3. Obiceiul rău: funcții lungi

Dacă adăugați un cod mai mult la această metodă, atunci suportul va deveni aproape imposibil.

Obișnuință obișnuită: funcții ușor de gestionat și focalizate

Listarea 4 demonstrează o versiune mai compactă și mai lizibilă a metodei anterioare. În acest exemplu, metoda lungă este împărțită în metode mai mici, fiecare realizând o singură sarcină și o face bine. Codul rezultat este mai ușor de reutilizat în viitor și este mai ușor de testat.

Listing 4. Obiceiul bun: funcții specifice, ușor de gestionat

Separarea metodelor lungi în cele mai scurte face sens până la o anumită limită, așa că fiți atenți și nu exagerați. Puteți rupe codul astfel încât să rămână la fel de greu de citit ca înainte, când a fost o singură funcție.

Documentează-ți codul

Mod obișnuit: documentare absentă și excesivă a funcțiilor

Lista 5. Obiceiul rău: lipsa și documentarea excesivă a funcțiilor

Un obicei bun: documentarea funcțiilor și a claselor

Lista 6. Obiceiul bun: documentarea funcțiilor și a claselor

Efectuați erori

Este bine cunoscut faptul că atunci când se scriu aplicații stabile, cantitatea de cod pentru manipularea erorilor trebuie să respecte regula 80/20: 80% din cod se ocupă de manipularea excepțiilor și de validare, 20% din cod efectuează lucrarea reală. Este destul de natural ca, atunci când scrii codul, mulți dezvoltatori sunt ghidați de cel mai favorabil scenariu (cale fericită). Acest cod funcționează bine în așa-numitul. Situația "de bază", atunci când toate datele sunt valide și toate condițiile sunt conform așteptărilor. Cu toate acestea, pe durata de viață a aplicației, un astfel de cod poate arăta instabilitatea acestuia. Pe de altă parte, puteți petrece prea mult timp scriind cod pentru condiții care nu s-ar întâlni niciodată.

Un obicei bun este de a găsi un echilibru rezonabil între cantitatea suficientă de manipulare a erorilor și refuzul de a vă rafina codul, ceea ce nu se poate termina niciodată.

Mod de rău: absența completă a manipulării erorilor

Codul din Lista 7 arată două obiceiuri proaste. Una dintre ele este lipsa verificării parametrilor de intrare, chiar dacă știți că în acest moment parametrul într-o anumită stare va arunca o excepție în metoda dvs. Al doilea este că codul numește o metodă care poate arunca o excepție nefolosită. Acest cod va determina dezvoltatorul sau o persoană care îl însoțește să speculeze despre sursa problemelor atunci când încep să apară.

Lista 7. Obiceiul rău: absența completă a manipulării erorilor

Obișnuință obișnuită: programare cu protecție

Listing 8. Un obicei bun: programare cu protecție

În general, verificarea parametrilor se referă la faza de validare - care se va dovedi folositoare pentru oricine care vă va folosi funcțiile (dacă dorește ca parametrii să îndeplinească anumite condiții). Cu toate acestea, ar trebui să verificați acești parametri și să aruncați excepții semnificative.

  • Gestionați excepțiile cât mai aproape de problemă posibil.
  • Manipulați fiecare excepție într-un mod specific.

Nu utilizați niciodată operația "copiere și lipire"

Abilitatea de a copia codul dintr-un singur loc și apoi să îl lipiți într-un alt loc în codul dvs. este o sabie cu două tăișuri. Pe de o parte, acest lucru vă salvează de la multe greșeli care apar atunci când utilizați tastatura pentru a introduce manual un cod dintr-un exemplu sau dintr-un șablon. Pe de altă parte, contribuie la "proliferarea" fragmentelor de cod similare.

Folosiți maximă precauție atunci când copiați codul între diferite părți ale aplicației. Când vă aflați în situația de a face acest lucru, opriți-vă și întrebați cum puteți să rescrieți copia codului pentru a vă asigura că este reutilizată. Plasarea codului într-un singur loc simplifică foarte mult întreținerea ulterioară, deoarece modificările trebuie făcute numai la un moment dat.

Mod obișnuit: fragmente de cod similare

Lista 9 prezintă mai multe metode care sunt aproape identice, cu excepția câtorva valori. Există instrumente care vă vor ajuta să găsiți codul obținut prin copiere și lipire (consultați Resurse).

Listing 9. Obiceiul rău: fragmente de cod similare

Obiceiul bun: funcții reutilizabile cu parametri

Lista 10 arată codul modificat, cu conversia blocului copiat într-o singură metodă. Alte metode au fost de asemenea modificate pentru a delega munca lor la noua metodă. Construcția unei metode generale durează ceva timp la etapa de proiectare; În plus, trebuie să vă opriți și să gândiți, în loc să utilizați instinctiv operația "copie și lipire". Cu toate acestea, veți compensa mai mult timpul petrecut ulterior, când trebuie să faceți modificări.

Listing 10. Obiceiul bun: funcții reutilizabile cu parametri

concluzie

Dacă dezvoltați obiceiurile bune descrise în acest articol când scrieți cod PHP, veți putea crea un cod care va fi ușor de citit, înțeles și întreținut. Construirea unui program simplu cu cod vă va permite să depanați, să remediați și să extindeți codul cu un nivel mai scăzut de risc.

Folosirea unor nume bune și organizarea codului sub formă de fragmente mai mici face mai ușor de citit. Documentarea scopului codului dvs. facilitează înțelegerea intențiilor dvs. și ușurează extinderea. Manipularea corectă a erorilor face codul mai robust. Și, în cele din urmă, renunțarea la o "cârjă" ca operație de copiere / lipire vă permite să păstrați codul curat.

Descărcați resurse

Subiecte conexe







Articole similare

Trimiteți-le prietenilor: