această secțiune este, de asemenea, într-adevăr o condiție prealabilă pentru codificare, după cum subliniază McConnell: „stabiliți convenții de programare înainte de a începe programarea. Este aproape imposibil de a schimba codul pentru a le potrivi mai târziu.”

așa cum sunt enumerate aproape de sfârșitul convențiilor de codificare, există convenții diferite pentru diferite limbaje de programare, deci poate fi contraproductiv să aplici aceleași convenții în diferite limbi. Este important să rețineți că nu există o convenție de codificare specială pentru niciun limbaj de programare. Fiecare organizație are un standard de codificare personalizat pentru fiecare tip de proiect software. Prin urmare, este imperativ ca programatorul să aleagă sau să alcătuiască un anumit set de linii directoare de codificare înainte de începerea proiectului software. Unele convenții de codificare sunt generice, care nu se pot aplica pentru fiecare proiect software scris cu un anumit limbaj de programare.

utilizarea convențiilor de codificare este deosebit de importantă atunci când un proiect implică mai mult de un programator (au existat proiecte cu mii de programatori). Este mult mai ușor pentru un programator să citească codul scris de altcineva dacă tot codul respectă aceleași convenții.

pentru câteva exemple de convenții de codificare proaste, Roedy Green oferă un articol lung (limbă-în-obraz) despre cum să producă un cod care nu poate fi întreținut.

CommentingEdit

Din cauza restricțiilor de timp sau a programatorilor entuziaști care doresc rezultate imediate pentru codul lor, comentarea codului ocupă adesea un loc în spate. Programatorii care lucrează în echipă au considerat că este mai bine să lase comentarii în urmă, deoarece codificarea urmează de obicei cicluri sau mai multe persoane pot lucra la un anumit modul. Cu toate acestea, unele comentarii pot reduce costul transferului de cunoștințe între dezvoltatorii care lucrează la același modul.

în primele zile de calcul, o practică comentând a fost de a lăsa o scurtă descriere a următoarelor:

1. numele modulului
2. scopul modulului
3. descrierea modulului
4. autor Original
5. modificări
6. autori care au modificat Codul cu o descriere a motivului pentru care a fost modificat.

„descrierea modulului” ar trebui să fie cât mai scurtă posibil, dar fără a sacrifica claritatea și exhaustivitatea.cu toate acestea, ultimele două elemente au fost în mare parte depășite de apariția sistemelor de control al revizuirii. Modificările și autorul lor pot fi urmărite în mod fiabil prin utilizarea unor astfel de instrumente, mai degrabă decât prin utilizarea comentariilor.

De asemenea, dacă se folosește o logică complicată, este o bună practică să lăsați un comentariu „blocați” lângă acea parte, astfel încât un alt programator să poată înțelege exact ce se întâmplă.

testarea unitară poate fi un alt mod de a arăta cum se intenționează utilizarea codului.

convenții de denumire

utilizarea convențiilor de denumire corespunzătoare este considerată o bună practică. Uneori programatorii tind să utilizeze X1, Y1 etc. ca variabile și uitați să le înlocuiți cu cele semnificative, provocând confuzie.

se consideră de obicei o bună practică utilizarea numelor descriptive.

exemplu: o variabilă pentru luarea în greutate ca parametru pentru un camion poate fi numită Trkweight sau TruckWeightKilograms, TruckWeightKilograms fiind cea preferabilă, deoarece este ușor de recunoscut. A se vedea camelCase denumirea variabilelor.

Păstrați codul simpleEdit

codul pe care un programator îl scrie ar trebui să fie simplu. Logica complicată pentru realizarea unui lucru simplu ar trebui menținută la minimum, deoarece codul ar putea fi modificat de un alt programator în viitor. Logica implementată de un programator poate să nu aibă sens perfect pentru altul. Deci, păstrați întotdeauna Codul cât mai simplu posibil.

de exemplu, luați în considerare aceste linii echivalente de cod C:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

și

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

și

return hours < 24 && minutes < 60 && seconds < 60;

abordarea 1, care este mult mai frecvent utilizată, este considerabil mai mare decât a 3-a. În special, consumă de 5 ori mai mult spațiu vertical pe ecran (linii) și 97 de caractere față de 52 (deși instrumentele de editare pot reduce diferența de tastare reală). Cu toate acestea, este discutabil, ceea ce este „mai simplu”. Primul are un explicit dacă / apoi altceva, cu o valoare returnată explicită în mod evident legată de fiecare; chiar și un programator novice nu ar trebui să aibă dificultăți în a-l înțelege. Al 2-lea aruncă doar bretelele, tăind dimensiunea „verticală” la jumătate, cu puține schimbări în complexitatea conceptuală. În majoritatea limbilor, declarațiile „return” ar putea fi, de asemenea, anexate la liniile anterioare, aducând dimensiunea „verticală” la încă o linie decât forma a 3-a.

a treia formă minimizează în mod evident dimensiunea, dar poate crește complexitatea: Lasă valorile” adevărate „și” false „implicite și amestecă noțiunile de” condiție „și”valoare returnată”. Este probabil evident pentru majoritatea programatorilor, dar un novice ar putea să nu înțeleagă imediat că rezultatul evaluării unei condiții este de fapt o valoare (de tip Boolean, sau echivalentul său în orice limbă) și, prin urmare, poate fi manipulat sau returnat. În exemple mai realiste, formularul 3 ar putea avea probleme din cauza priorității operatorului, returnând probabil un tip neașteptat, unde formularele anterioare ar raporta în unele limbi o eroare. Astfel, „simplitatea” nu este doar o chestiune de lungime, ci de structură logică și conceptuală; a face Codul mai scurt îl poate face mai puțin sau mai complex.

pentru programe mari, de lungă durată, folosind alternative verbose ar putea contribui la bloat.

compactitatea poate permite programatorilor să vizualizeze mai mult cod pe pagină, reducând gesturile de defilare și apăsările de taste. Având în vedere de câte ori Codul ar putea fi vizualizat în procesul de scriere și menținere, s-ar putea ridica la o economie semnificativă în apăsările de taste ale programatorului în viața codului. Acest lucru s-ar putea să nu pară semnificativ pentru un student care învață mai întâi să programeze, dar, atunci când produce și întreține programe mari, reducerea numărului de linii de cod permite o mai mare parte a codului să se potrivească pe ecran, simplificarea minoră a codului poate îmbunătăți productivitatea și, de asemenea, poate diminua tulpina degetelor, încheieturii mâinii și ochilor, care sunt probleme medicale comune suferite de programatorii de producție și lucrătorii informaționali.

codarea Terser accelerează compilarea foarte puțin, deoarece mai puține simboluri trebuie procesate. Mai mult, abordarea a 3-A poate permite compararea mai ușoară a liniilor de cod similare, în special atunci când multe astfel de construcții pot apărea pe un singur ecran în același timp.

în cele din urmă, foarte terses machete pot utiliza mai bine moderne Display-uri de calculator cu ecran lat, în funcție de aspectul monitorului și de configurare. În trecut, ecranele erau limitate la 40 sau 80 de caractere (astfel de limite își au originea mult mai devreme: manuscrise, cărți tipărite și chiar suluri, au folosit de milenii linii destul de scurte (vezi de exemplu Biblia Gutenberg). Ecranele moderne pot afișa cu ușurință 200 sau mai multe caractere, permițând linii extrem de lungi. Majoritatea stilurilor și standardelor moderne de codificare nu ocupă întreaga lățime. Astfel, dacă utilizați o fereastră la fel de largă ca ecranul, se pierde mult spațiu disponibil. Pe de altă parte, cu mai multe ferestre sau folosind un IDE sau alt instrument cu diverse informații în geamurile laterale, lățimea disponibilă pentru cod este în intervalul familiar din sistemele anterioare.

de asemenea, este de remarcat faptul că sistemul vizual uman este foarte afectat de lungimea liniei; liniile foarte lungi cresc ușor viteza de citire, dar reduc înțelegerea și adaugă erori de urmărire a ochilor. Unele studii sugerează că liniile mai lungi se descurcă mai bine online decât cele tipărite , dar acest lucru se ridică doar la aproximativ 10 inci și, în principal, pentru viteza brută de citire a prozei.

PortabilityEdit

codul programului nu trebuie să conțină valori „codificate” (literale) care se referă la parametrii de mediu, cum ar fi căile absolute ale fișierelor, numele fișierelor, numele utilizatorilor, numele gazdei, adresele IP, adresele URL, porturile UDP / TCP. În caz contrar, aplicația nu va rula pe o gazdă care are un design diferit de cel anticipat. Un programator atent poate parametriza astfel de variabile și le poate configura pentru mediul de găzduire în afara aplicației propriu-zise (de exemplu în fișiere de proprietăți, pe un server de aplicații sau chiar într-o bază de date). Comparați mantra unui „punct unic de definiție” (SPOD).

ca extensie, resurse precum fișierele XML ar trebui să conțină și variabile, mai degrabă decât valori literale, altfel aplicația nu va fi portabilă într-un alt mediu fără a edita fișierele XML. De exemplu, cu aplicațiile J2EE care rulează într-un server de aplicații, astfel de parametri de mediu pot fi definiți în domeniul de aplicare al JVM și aplicația ar trebui să obțină valorile de acolo.

ScalabilityEdit

cod de Design cu scalabilitate ca un obiectiv de proiectare, deoarece foarte des în proiecte software, noi caracteristici sunt întotdeauna adăugate la un proiect care devine mai mare. Prin urmare, facilitatea de a adăuga noi caracteristici la o bază de cod software devine o metodă neprețuită în scrierea software-ului

Reutilizabilitateedit

reutilizarea este un obiectiv de proiectare foarte important în dezvoltarea de software. Reutilizarea reduce costurile de dezvoltare și, de asemenea, reduce timpul de dezvoltare dacă componentele sau modulele reutilizate sunt deja testate. Foarte des, proiectele software încep cu o linie de bază existentă care conține proiectul în versiunea sa anterioară și, în funcție de proiect, multe dintre modulele și componentele software existente sunt refolosite, ceea ce reduce timpul de dezvoltare și testare, crescând astfel probabilitatea de a livra un proiect software la timp.

Ghid de construcție pe scurtedit

o prezentare generală a tuturor celor de mai sus: