Free Press

Bine ați venit în minunata lume a dezvoltării de software. Pregătiți-vă pentru o călătorie incitantă și palpitantă, plină de cod, reguli și iar cod. Și am menționat că există reguli? Dacă sunteți o persoană care este familiarizată cu codarea, atunci conceptul de standarde de codare nu este ceva nou pentru dumneavoastră. Este posibil să fiți un susținător puternic al acestor linii directoare sau un luptător pentru libertate care crede că codul este o formă de exprimare. Oricare ar fi cazul, nu strică să ne uităm la unele dintre cele mai bune practici atunci când vine vorba de a scrie o bucată bună de cod.
Merită să menționăm că, deși există standarde de codare – acestea există în multe variante și, adesea, sunt doar linii directoare care nu trebuie să fie respectate. Dacă nu doriți să scrieți cod bun, atunci probabil că ar trebui să respectați o anumită formă de standarde.

Scrieți comentarii și documentație

Poate că unul dintre primele lucruri pe care le învățați ca dezvoltator este să vă comentați codul. La început poate părea o pierdere de timp, urmând mentalitatea „Dacă și ei sunt dezvoltatori – îl pot înțelege”. Deși este adevărat în unele cazuri, comentarea codului dvs. și furnizarea unei documentații adecvate îi va ghida pe ceilalți dezvoltatori prin algoritmul și logica pe care le-ați implementat. Dar nu vă lăsați dus de val și nu comentați fiecare linie de cod! Codul evident ar trebui lăsat așa cum este.

Scrieți un cod lizibil, dar eficient

Codurile lizibile sunt ușor de urmărit, dar folosesc optim spațiul și timpul. Atunci când scrieți cod, este posibil ca deseori să doriți să-l scrieți în cât mai puține rânduri posibil. Poate că puteți scrie o metodă sau o funcție întreagă într-un singur rând, dar acest lucru nu face decât să-l facă mai greu de citit și de înțeles.

Utilizați metode ajutătoare

Este o bună practică să păstrați codul concis și succint. O metodă ar trebui să implementeze doar ceea ce trebuie să facă. Dacă o parte a implementării dvs. face altceva, puneți-o într-o metodă separată și apelați-o în cadrul metodei dvs.

Dacă se poate evita, NU faceți hard-code!

Unele lucruri care ar trebui să fie hard-codate sunt constantele. Asta este tot.

Scrieți cazuri de testare. Nu uitați de cazurile limită: 0s, șiruri/liste goale, nulls, etc.

În acest fel știți ce face metoda dumneavoastră, ce ia și ce ar trebui să returneze. Veți ști când ar trebui să funcționeze sau când ar trebui să eșueze. O funcție ar trebui să se bazeze întotdeauna pe cazuri de testare; nu pe teste pe funcții.

Scrieți cod lizibil, dar eficient.Respectați standardele de codare ale proiectului dvs. curent

„PRACTICILE PERSONALE DISCIPLINATE POT REDUCE RATELE DE INTRODUCERE A DEFECTELOR CU PÂNĂ LA 75 DE PROCENTE”

Care proiect/companie are propriile standarde de codare. Unii ar putea prefera un stil în detrimentul altuia atunci când vine vorba de lucruri precum convențiile de denumire, structura fișierelor și spațierea.
Există IDE-uri în care puteți seta stilul preferat, care vă va corecta automat atunci când salvați. Este mai ușor de citit și, prin urmare, de înțeles, atunci când toate fișierele din proiecte folosesc același stil, convenție de denumire, spațiere etc.

Utilizați meniul derulant al IDE-ului dumneavoastră

Nu este atât de mult un standard, ci o bună practică, acestea sunt foarte utile și vă vor ajuta să faceți mai puține erori de codificare.

De exemplu:
Dacă doriți să redenumiți o variabilă sau o metodă, pur și simplu folosiți opțiunea „refactor” a IDE-ului dvs. și acesta va schimba toate apelurile la numele acelei metode/variabile. Nu trebuie să le schimbați una câte una, ceea ce va face ca codul dumneavoastră să fie predispus la erori/erori.
Dacă doriți să creați metode getter/setter pentru toate variabilele dumneavoastră private, trebuie doar să utilizați „create getter/setter” și IDE va crea automat metodele pentru dumneavoastră.

API-urile sunt la îndemână

„PROIECTELE SOFTWARE ACTUALE cheltuiesc aproximativ 40-50% din efortul lor pe refacerea evitabilă”

Înainte de a implementa o metodă, asigurați-vă că acestea nu sunt disponibile pentru a fi utilizate. Nu trebuie să codificați dacă puteți pur și simplu să importați funcționalitatea. Aceasta face viața unui dezvoltator super ușoară.
Celebrul proverb este „Nu reinventați roata” și este valabil în multe cazuri. Cu toate acestea, ar trebui să luați întotdeauna în considerare implicațiile importului unei biblioteci, mai ales dacă aceasta este terță parte. În afară de posibilele probleme de licențiere, s-ar putea să vă umflați pur și simplu baza de cod. Dacă tot ce aveți nevoie este o metodă care convertește temperaturile, nu trebuie să importați o bibliotecă care face asta și alte o sută de lucruri.

Programare în perechi/revizuirea codului

„PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Acestea sunt foarte utile atunci când vine vorba de refactorizarea codului dumneavoastră. Alții ar putea vedea o implementare mai bună pentru a vă optimiza codul sau pur și simplu pentru a vă face codul mai elegant. De asemenea, se asigură că dezvoltatorii aderă la standarde și că munca este verificată de două ori. În plus față de toate acestea, este o modalitate minunată pentru dezvoltatori de a învăța unii de la alții.

BACKUP ȘI SALVAȚI-VĂ LUCRAREA FOARTE des

Suficient spus. Baterie descărcată, pană de curent, eroare de software, incendiu, dezastru nuclear – toate acestea pot duce la pierderea datelor. Să vă asigurați că salvați des și că vă salvați codul pe un fel de sistem de control al versiunilor este o modalitate simplă de a vă asigura că codul dvs. rămâne în siguranță.

Standardele de codare și cele mai bune practici sunt un subiect imens – unul care poate continua pe mai multe pagini. De fapt, dacă doriți vreodată să citiți despre standardele de codare Java, Oracle are exact asta. Aplicarea acestor standarde și practici variază, de asemenea, în funcție de aplicație – fie că lucrați la un proiect corporativ uriaș, fie că vă ajutați frățiorul la teme. În funcție de mulți factori, depinde în cele din urmă de dumneavoastră să vă asigurați că codul pe care îl dezvoltați este un cod bun.

Disclaimer: Toate punctele de vedere sau opiniile prezentate în această postare pe blog sunt exclusiv ale autorului și nu le reprezintă în mod necesar pe cele ale Aversan Inc.

.