Inginerie Software

Curs 11

Standarde de codificare

1. Importanţa standardelor de codificare

Standardele de codificare pentru Java sunt importante pentru ca ele conduc la o mai
mare consistenta in interiorul codului scris de dvs. si cel scris de colegii dvs. de echipa. O
consistenta mai mare conduce la un cod ce este mai usor de inteles cea ce inseamna ca este
mai usor de dezvoltat si de intretinut.
Un tel important in cursul dezvoltarii este acela de a asigura transmiterea codului dvs.
catre un alt dezvoltator sau echipa de dezvoltare in asa fel incat ei sa poata continua
intretinerea si imbunatatirea codului scris de dvs. fara a fi necesara investirea unui efort
nerezonabil pentru a intelege codul dvs. Daca fiecare isi scrie codul in felul sau atunci aceasta
va face foarte dificila folosirea codului in cadrul echipei de devoltatori, ducand la cresterea
costului aferent dezvoltarii si intretinerii codului.

Prima directivă

Nici un standard nu este perfect si nici un standard nu este aplicabil in toate situatiile.
In cazul in care aplicarea standardului nu este posibila aplicati prima directiva :

“Cand incalcati standardul, documentati.”

Toate regulile pot fi incalcate cu exceptia Primei Directive.

2. Standarde pentru crearea numelor

1. Folositi descriptori in limba Engleza care sa descrie in mod clar variabilele /

campurile / clasele. NU folositi descriptori de genul tm1, ag2 , dg3 sau Fn.
2. Utilizati terminologie aplicabila domeniului pentru care scrieti cod.
3. Folositi litere mici si litere mari pentru a face numele mai lizibile. Capitalizati prima
litera a fiecarui cuvant acolo unde este cazul.
4. Folositi abrevierile cu cumpatare, iar atunci cand le utilizati faceti-o in mod inteligent
si in mod consecvent.

1
Inginerie Software

5. Evitati folosirea numelor prea lungi. Lungimea maxima a numelor este de 15

caractere. Recomandabil maxim 15 caractere.
6. Evitati folosirea numelor care sunt similare sau difera doar prin capitalizarea unor
litere.
7. Evitati folosirea caracterului ‘_’ (underscore) la inceputul sau la sfarsitul numelor.

3. Standarde de bază pentru o buna documentatie

1. Comentariile trebuie sa imbunatateasca claritatea codului dvs;

2. Daca un program nu merita sa fie documentat, atunci probabil nici nu merita sa fie
rulat;
3. Evitati decoratiile. Nu folositi chenare pentru comentariile dvs;
4. Comentariile trebuie sa fie cat mai simple, clare si la obiect;
5. Scrieti documentatia inainte de a scrie codul. Cel mai bun mod de a documenta codul
este de a scrie comentariile inainte de a scrie codul;
6. Documentati de ce a fost facut ceva nu numai ceea ce se face.

4. Tehnici pentru scrierea codului

Tehnicile utilizate pentru scrierea codului sunt:

• Documentarea codului
• Indentarea codului
• Utilizarea spaţiilor
• Regula celor 30 de secunde
• Scrieti linii de cod scurte, o singura instructiune pe linie
• Specificarea ordinii operatiilor

Documentarea codului

Retineti ca daca codul dvs. nu merita documentat atunci probabil ca nu merita sa fie
rulat.

Indentarea codului

Unul din modurile prin care imbunatatiti legibilitatea codului este sa folositi aceiasi
aliniere pentru toate liniile unui bloc de cod. Codul din interiorul unui bloc trebuie sa fie
aliniat uniform spre interior cu o unitate. Prin unitate se intelege un Tab (1 Tab = 4 spaţii).
Acolada deschisa ( { ) va fi pusa pe linia imediat urmatoare liniei ce defineste blocul iar
acolada inchisa ( } ) va fi aliniata cu cea deschisa. Liniile de cod cuprinse intre cele doua
acolade vor fi identate cu un Tab.
Exemplu :
/** comentarii metoda
de remarcat tipul comentariului
*/
protected int getBranchNumber()
{

2
Inginerie Software

if (branchNumber == 0)
{
// comentariul blocului
setBranchNumber(1000);
}
}

Utilizarea spaţiilor

Una sau mai multe linii goale formeaza un whitespace. Utilizati o singura linie goala
pentru a delimita grupurile logice din codul dvs. (ex. structurile de control) si doua linii goale
pentru a delimita metodele.

Regula celor 30 de secunde

Un alt programator care se uita la o metoda scrisa de dvs. trebuie sa inteleaga ce face, de
ce face si cum face cea ce trebuie sa faca metoda in mai putin de 30 de secunde. In caz contrar
codul este prea dificil de intretinut si va trebui sa-l imbunatatiti. Deci 30 de secunde.

Scrieti linii de cod scurte, o singura instructiune pe linie

Codul dvs. trebuie sa faca un singur lucru pe o linie. Ori de cate ori incercati sa faceti
mai multe lucruri intr-o singura linie de cod, faceti codul mai greu de inteles.

Specificati ordinea operatiilor

O alta cale prin care usurati intelegerea codului dvs. este aceea de a folosi paranteze
rotunde pentru a specifica ordinea exacta a operatiilor in codul dvs.

5. Tipuri de comentarii JAVA

Sunt trei tipuri de comentarii JAVA, fiecare cu domeniul sau de utilizare :

1. Comentarii /** … */ pentru documentatie, inaintea declaratiei interfetelor, claselor sau

metodelor;
2. In stilul C /* … */ pentru invalidarea unei portiuni de cod ce nu mai este necesara
momentan sau in scopul testarii codului;
3. Comentarii simple Java // informatii privind ce si/sau de ce in interiorul metodelor,
poate fi folosita si pe aceiasi linie cu codul (inlining).

6. Reguli clase, interfete, pachete si unitati de compilare

In cele ce urmeaza vor fi prezentate regulile si conventiile utilizate la scrierea codului in

cazul claselor, interfetelor, pachetelor si a unitatilor de compilare.

6.1 Reguli pentru clase

Numele claselor

Conventia standard Java este aceea de a folosi descriptori formati din cuvinte intregi din
limba Engleza care incep cu litera mare, restul literelor fiind litere mici.

3
Inginerie Software

Exemple :
Customer
OrderItem

Documentarea claselor

Urmatoarele informatii trebuie sa apara imediat inaintea definitiei clasei:

1. Scopul clasei. Ceilalti dezvoltatori trebuie sa cunoasca scopul general al clasei;
2. Erori de functionare cunoscute. In cazul in care clasa prezinta dificultati in
functionare in anumite conditii, acestea trebuie prezentate;
3. Istoria dezvoltarii / intretinerii clasei. Se vor documenta etapele dezvoltarii clasei
precum si modificarile efectuate asupra clasei, cine si ce modificari a facut, cine a
cerut modificarile;

Declararea claselor

Unul din modurile in care puteti face clasele dvs. mai usor de inteles este de a le declara
respectand urmatoare ordine :

1. Camputile statice;
2. Campurile publice;
3. Campurile protected;
4. Campurile private;
5. Constructorii;
6. Metoda finalize();
7. Metodele statice;
8. Metodele public;
9. Metodele protected;
10. Metodele private.

In interiorul fiecarui grup practica comuna este de a le lista in ordine alfabetica.

6.2 Reguli pentru interfete

Numele interfetelor

Conventia standard Java este aceea de a folosi descriptori formati din cuvinte intregi din
limba Engleza care incep cu litera mare, restul literelor fiind litere mici.

Documentarea interfetelor

Comentariile vor fi scrise imediat inaintea definitiei interfetei si va contine:

1. Scopul, inainte ca alti dezvoltatori sa foloseasca interfata, ei trebuie sa inteleaga

conceptul pe care il incapsuleaza;
2. Cum ar trebuie sau nu ar trebui folosita interfata.

4
Inginerie Software

6.3 Reguli pentru pachete

Numele pachetelor

Regulile privind denumirea pachetelor sunt urmatoarele :

1. Identificatorii sunt separati prin punct;
2. Pachetele standard de distributie java de la SUN incep cu identificatorul 'java';
3. Pachetele locale incep cu un identificator ce nu are toate literele majuscule;
4. Numele pachetelor globale incep cu numele inversat al domeniului Internet al
organizatiei.

Documentarea pachetelor

Vor fi create unul sau mai multe documente externe in care va fi descris scopul pachetului
dezvoltat. Documentul va fi in format HTML, numit [Link] pentru fiecare pachet, fiind
amplasat in directorul corespunzator pachetului. Pentru fiecare pachet documentatia va
contine :
1. Considerentele ce au stat la baza crearii pachetului, pentru o buna intelegere a
functionalitatii pachetului;
2. Clasele continute in pachet. Va fi inclusa o lista a claselor si interfetelor din pachet cu
o descriere scurta a fiecarei clase sau interfete.

6.4 Reguli pentru unitati de compilare

Numele unitatilor de compilare

O unitate de compilare, in acest caz fisierul ce contine codul sursa va fi denumite dupa
numele clasei primare sau interfetei declarata in cadrul sursei. Folositi acelasi nume cu cel al
clasei/interfetei, respectand literele mari/mici, extensia fisierului fiind '.java'.

Documentarea unitatilor de compilare

Desi trebuie sa incercati sa aveti o singura clasa sau interfata definita intr-un fisier, in
anumite situatii este necesar sa definiti mai multe clase in acelasi fisier. Regula generala este
ca daca singurul scop al clasei B este sa incapsuleze fanctionalitate ce este necesara doar
clasei A, atunci are sens ca, clasa B sa apara in acelasi fisier sursa cu clasa A. Avand in
vedere acest lucru regulile privind documentarea unitatilor de compilare vor fi dupa cum
urmeaza :
1. In cazul fisierelor ce contin mai multe clase, puneti la dispozitie o lista cu toate clasele
continute in fisier;
2. Numele fisierului si/sau informatii de identificare, numele fisierului va fi scris la
inceputul sau;
3. Informatii referitoare la Copyright.

5
Inginerie Software

7. Standarde pentru metode

De retinut ca cea mai mare parte din viata unei aplicatii o constituie intretinerea si nu
dezvoltarea. Codul scris azi va fi folosit multi ani iar intretinerea si actualizarea lui va fi
facuta de o alta persoana decat cea care l-a scris.

7.1 Numele metodelor

Metodelor vor fi denumite utilizand descrierea completa in Engleza, folosind litera mare
pentru prima litera a cuvintelor ce formeaza denumirea, mai putin primul cuvant care incepe
cu litera mica.
Exemple:
o openAccount()
o printMailingLabel()
o save()
o delete()
Numele metodelor cu functie speciala Getters si Setters precum si constructorii se vor
forma urmand regulile de mai jos:

Getters

Sunt metode ce intorc valoarea unui camp. Numele va fi format prin prefixarea cu ‘get’ a
numelui campului cu exceptia campurilor de tip boolean ce vor fi prefixate cu ’is’ in loc de
‘get’.
Exemple:

• getFirstName() - intoarce prenumele (String)

• isAtEnd() - intoarce o valoare booleana true sau false

Setters

Sunt metode ce modifica valoarea unui camp. Numele va fi format prin prefixarea cu ‘set’
a numelui campului indiferent de tipul campului.

Exemple:

• setFirstName(String aName)
• setAtEnd(boolean isAtEnd)

Constructors

Sunt metode in care se executa orice initializare necesara atunci cand obiectul este creat
pentru prima data. Numele este acelasi cu cel al clasei. Aceasta conventie a fost stabilita de
catre SUN si trebuie respectata cu strictete.

Exemple:

• Customer()

6
Inginerie Software

• SavingsAccount()

7.2 Vizibilitatea metodelor

Pentru un bun design, regula generala este de a fi cat se poate de restrictivi atunci cand
stabiliti vizibilitatea unei metode. Daca o metoda nu trebuie sa fie publica atunci faceti-o
protected, si daca nu e necesar sa fie protected faceti-o private.

7.3 Documentarea metodelor

Maniera in care documentati o metoda va fi in cele mai multe cazuri factorul decisiv
daca aceasta poate sau nu poate fi inteleasa si deci daca va fi posibila intretinerea ei si daca va
putea fi extinsa.

Antetul metodelor

Fiecare metoda va avea un antet care va include toate informatiile necesare pentru
intelegerea ei. Introducerea acestor informatii este obligatorie.
Antetul va include urmatoarele informatii :
1. Ce si de ce face metoda cea ce face.
Documentand ce face metoda se poate determina mult mai usor daca codul dvs. poate
fi refolosit. Documentand de ce face va usura intretinerea ulterioara a codului.
2. Lista parametrilor ce trebuiesc folositi la apelarea metodei.
Trebuie sa indicati lista parametrilor necesari pentru apelarea functiei si cum vor fi
acestia folositi. (vezi tag-ul javadoc @param)
3. Ce intoarce metoda respectiva.
Trebuie sa documentati ceea ce intoarce metoda, daca intoarce un obiect/valoare. (vezi
tag-ul javadoc @return)
4. Erorile (bugs) cunoscute.
In cazul in care sunt probleme (bugs) ce afecteaza functionarea metodei, acestea vor fi
documentate pentru ca ceilalti programatori sa cunosca dificultatile/slabicunile pe care
le are metoda.
5. Exceptiile aruncate de metoda.
Documentati toate exceptiile aruncate astfel incat ceilalti programatori sa stie ce
exceptii trebuiesc interceptate atunci cand apleaza metoda dvs. (vezi tag-ul javadoc
@exception)
6. Decizii de vizibilitate.
In cazul in care hotarati ca metoda trebuie sa fie publica, documentati care sunt
motivele ce au condus la luarea acestei decizii.
7. Modificarile suferite de un obiect in interiorul metodei.
Daca metoda modifica un obiect documentati ce se intampla cu obiectul.
8. Istoricul modificarilor suferite de metoda respectiva.
Includeti informatii privind data cand a fost facuta modificarea, cine a facut-o, cine a
solicitat modificarea, cine a testat modificarea si cine a dat OK-ul.

7
Inginerie Software

9. Exemple de apelare a metodei respective, daca este necesar.

Cel mai simplu mod pentru a intelege functionarea unei bucati de cod este prin
exemple.
10. Pre-conditii si post-conditii, acolo unde este cazul.
Pre-conditiile sunt conditiile ce trebuiesc indeplinite pentru buna functionare a metodei.
Post-conditia este o proprietate sau o afirmatie care este adevarata dupa ce metoda a terminat
de rulat.
Este important de retinut ca trebuie sa documentati doar cea ce poate aduce mai multa
claritate codului.
Nu veti documenta toate punctele prezentate mai sus pentru fiecare metoda a unei clase
dar veti documenta cele care sunt aplicabile fiecarei metode in parte.

Corpul metodelor

Fiecare metoda va contine comentarii care sa descrie functionarea metodei. Introducerea

acestor informatii este obligatorie.
Se vor folosi doua tipuri de comentarii:
• Stil C, /* … */, utilizate pentru invalidarea temporara a unor portiuni de cod
• Comentarii simple, //, ce pot fi folosite singure pe o linie sau pe liniile cu cod
(inline)
Documentati intodeauna :
1. Structurile de control
2. De ce si ce anume face codul dvs.
3. Variabilele locale
4. Codul dificil sau complex
5. Ordinea de executie, daca este necesara pastrarea unei anumite ordini de
executie a instructiunilor.
Tip – Documentati acoladele inchise mai ales in cazul structurilor imbricate

8. Reguli pentru campuri

8.1 Numele campurilor

La crearea numelui unui camp se va folosi principiul conform caruia numele va fi
format folosind urmatoarea abordare:
tipEeeee(Eeeee…)
unde :
• tip – indica tipul campului.
• Eeeee(Eeeee…) – este un descriptor complet in limba engelza care arata
continutul campului.
Exemple :

8
Inginerie Software

iCustomerAge - varsta clientului , de tip int;

dItemPrice - pretul , de tip double;

dbQuantity - cantitatea, de tip Double;

strDescription - denumirea produsului, de tip String;

8.2 Numele componentelor / obiectelor

La crearea numelui unei componente se va folosi principiul conform caruia numele va fi
format folosind urmatoarea abordare:
tipEeeee(Eeeee…)
unde :
o tip – indica tipul componentei.
o Eeeee(Eeeee…) – este un descriptor complet in limba engelza care reprezinta
numele componentei.
Exemple :
gpbOk - butonul OK , de tip MNGButton (push button);
dgPrices - DataGate cu preturile aferente unui produs , de tip WMNGDataGateAbstr;
ageQuantity - un agent incarcat cu o valoare ce reprezinta cantitatea, de tip
WMNGAgent;
outMessage - mesaj, de tip WMNGOutcome;

8.3 Numele constantelor

In Java, constantele, valori care nu se modifica, sunt implementate ca niste campuri
static final. Conventia este de a folosi cuvinte intregi in Engleza, toate scrise cu majuscule,
cuvintele fiind separate prin caracterul ‘_’ (underscore).
Exemple :

MINIMUM_BALANCE

DEFAULT_START_DATE

8.4 Numele colectiilor

Colectiile, cum ar fi un vector sau o matrice, vor fi denumite urmand principiul

prezentat la formarea numelor campurilor, deosebirea fiind ca descriptorii folositi vor fi la
plural pentru a indica ca este vorba de o colectie de valori.

8.5 Vizibilitatea campurilor

Toate campurile vor fi declarate private. Campurile nu vor fi acceate in mod direct ci
prin intermediul metodelor de acces (getters&setters).
Nu “ascundeti” nume

9
Inginerie Software

Ascunderea numelui se refera la o practica prin care se numeste o variabila locala,

argument sau camp cu acelasi nume (sau similar) cu o alta variabila, argument sau camp ce
are un domeniu de vizibilitate mai mare.

8.6 Documentarea campurilor

Fiecare camp trebuie documentat indeajuns astfel incat ceilalti dezvoltatori sa-l poata
intelege. Astfel, trebuie sa documentati :
1. Descrierea campului.
Pentru ca ceilalti sa stie cum sa-l foloseasca.
2. Documentati toti invariantii aplicabili.
Invariantul unui camp sunt conditiile care sunt intotdeauna adevarate despre el.
3. Exemple.
Pentru campurile care au reguli comerciale complexe atasate, trebuie sa prezentati
cateva exemple care sa ajute la intelegerea folosirii lui.
4. Decizii de vizibilitate.
Daca ati hotarat ca un camp trebuie sa fie oricum altfel decat private, atunci trebuie sa
documentati de ce ati luat aceasta decizie.

9. Folosirea metodelor de accesare (accessors)

In plus fata de folosirea conventiilor privind numele campurilor, pentru obtinerea unei
mentenabilitati mai bune a acestora, se vor folosi asa-numitele “metode de accesare” care
pun la dispozitie modul de actualizare sau de accesare a valorii unui camp. Metodele de
accesare sunt cu doua ‘arome’: setters (numite si modificatori) si getters. Un setter modifica
valoarea unei variabile in timp ce un getter obtine valoarea pentru dvs.

9.2 Numele accesorilor

Numele metodelor de accesare, getters, vor fi create prin prefixarea numelui campului
cu particula ‘get’ iar in cazul in care campul este de tip boolean va fi folosita particula ‘is’. In
cazul metodelor setters numele va fi format prin prefixarea cu particula ‘set’, indiferent de
tipul campului.

9.3 Vizibilitatea accesorilor

Intodeauna incercati sa faceti accesorii protected astfel incat doar subclasele sa poata
accesa campurile. Doar atunci cand o alta clasa, externa, trebuie sa acceseze un anumit camp
faceti accesorii corsepunzatori campului publici.

9.4 Utilitatea folosirii accesorilor

Un bun design al programului cauta sa izoleze parti ale programului impotriva
influentelor externe nenecesare, neintentionate sau nedorite. Accesorii pun la dispozitie
mijloace de control acestor contacte (influente).
Folosirea accesorilor imbunatateste mentenabilitatea programelor in urmatoarele feluri:
1. Actualizarea campurilor se face intr-un singur loc.

10
Inginerie Software

2. Aveti controlul complet asupra felului in care sunt accesate campurile si de

catre cine.
3. Prin incapsularea valorii constantelor si numelor claselor in metodele 'getter',
atunci cand acestea trebuiesc schimbate, actualizati valorile/numele numai in metodele'getter',
si nu in fiecare linie de cod unde aceste valori/nume sunt folosite.
4. Folosirea initalizarii lenese (lazy initialization) asigura ca toate campurile sunt
initializate si ca ele sunt initializate numai daca sunt necesare.
5. Atunci cand subclasele acceseaza campurile mostenite numai prin intermediul
metodelor de accesare corespunzatoare, este posibil sa fie facute modificari ale implementarii
campurilor superclasei fara ca acest lucru sa afecteze nici una din subclase.
6. Daca regulile comerciale referitoare la unul sau mai multe campuri se schimba,
puteti modifica metodele de acces pentru a oferi aceiasi functionalitate ca inainte de
modificarea regulilor comerciale.
7. Cu toate ca trebuie sa evitati "ascunderea numelor", folosirea accesorilor
reduce problemele legate de "ascunderea numelor" deoarece accesarea campurilor se face
numai prin intermediul metodelor de acces.

10. Reguli pentru variabile locale

O variabila locala este un obiect sau o valoare care este definita in interiorul unui bloc,
de obicei o metoda. Domeniul de valabilitate al unei variabile locale este blocul in care
aceasta este definita.

10.1 Numele variabilelor locale

In general, la alegerea numelor variabilelor locale se vor urma aceleasi reguli ca cele
pentru formarea numelui campurilor, adica folositi descriptori formati din cuvinte intregi in
limba Engleza scrise cu litere mici, prima litera a primului cuvant scrisa cu litera mica iar
urmatoarele cuvinte vor avea prima litera scrisa cu majuscula.
Exceptiile de la regula de mai sus sunt prezentate mai jos.
10.2 Numele fluxurilor (streams)
Acolo unde este deschis, utilizat si inchis un singur flux de intrare si/sau de iesire in
interiorul unei metode se vor folosi numele in si out. Daca fluxul este utilizat atat pentru
intrare cat si pentru iesire se va folosi numele inOut.

10.3 Numele contoarelor de ciclu

Pentru contoarele de ciclu se vor folosi i, j sau k.

10.4 Numele obiectelor exceptie

Pentru numele exceptiilor se va folosi e. Numele instantelor claselor de tip exceptie va
incepe cu e.

10.5 Declararea si documentarea variabilelor locale

Sunt mai multe reguli privind declararea si documentarea variabilelor locale. Acestea
sunt:

11
Inginerie Software

1. Declarati o singura variabila locala pe o linie de cod.

2. Documentati variabilele locale cu comentarii tip inline (endline comment). Trebuie sa
documentati la ce este folosita variabila locala si acolo unde este necesar si de ce.
3. Declarati toate variabilele locale la inceputul fiecarei metode.
4. Utilizati variabilele doar pentru un singur lucru, pentru cea ce au fost declarate. Ori
de cate ori folositi variabilele pentru alte motive decat cele pentru care au fost
declarate faceti codul mult mai greu de inteles. De asemenea creste probabilitatea
aparitiei erorilor datorate efectelor secundare nedorite cauzate de valorile variabilelor
locale ce provin din utilizarea lor anterioara.

11. Reguli pentru parametrii metodelor

11.1 Numele parametrilor

Parametrii vor fi numiti urmand regulile folosite la denumirea variabilelor locale, avand
prefixul "a" sau "an". Prefixul "a" sau "an" ajuta la deosebirea mai usoara a parametrilor de
variabilele locale si evita problema "ascunderii numelor".
Exemple:
aCustomer
anInventoryItem
anException

11.2 Documentarea parametrilor

Parametrii unei metode vor fi documentati in documentatia antet a metodei folosind tag-
ul @param (javadoc). Trebuie sa descrieti:
1. La ce este folosit parametrul, pentru ca ceilalti dezvoltatori sa cunoasca exact
contextul folosirii fiecarui parametru.
2. Restrictii si preconditii, daca este cazul documentati intervalul de valori pe care il
poate lua parametrul sau alte conditii ce trebuiesc indeplinite pentru o utilizare corecta
a metodei.
3. Exemple, daca nu este limpede ce anume trebuie sa fie parametrul dati unul sau mai
multe exemple.

12. Alte conventii si linii directoare privind codificarea

In cele ce urmeaza vor fi prezentate alte conventii si linii directoare utilizate la scrierea
codului.

12.1 Importarea claselor

La importarea claselor folositi nu importati intregul pachet, importati numai clasele care
va sunt necesare. Deci, nu este indicat să folositi :

import [Link].*;

însă sunteţi încurajaţi să folositi:

12
Inginerie Software

import [Link];
import [Link];
import [Link];

12.2 Optimizarea codului Java

Nu incercati sa optimizati tot codul si chiar de la inceput. Lasati optimizarea codului la
sfarsit deoarece portiunile de cod care au intr-adevar nevoie de optimizare sunt de regula
foarte mici si veti lua atunci decizia daca si ce portiuni de cod necesita optimizare.
Nu uitati ca un program lent care functioneaza corect este intotdeauna preferabil unui
program mai rapid care nu functioneaza!

12.3 Testarea codului

Atunci cand testati codul prefixati cu 'test' toate elementele folosite in procesul de
testare si nu sunt necesare in exploatare. Astfel, in momentul in care ati terminat testarea,
puteti indeparta mult mai usor aceste elemante.
Liniile directoare ce urmeaza va vor ajuta sa utilizati standardele de codificare
prezentate in acest document mai eficient:
1. Intelegerea standardelor. Rezervati-va timp pentru intelege de ce respectarea fiecarui
standard duce la o productivitate mai mare.
2. Credeti in aceste standarde. Intelegerea fiecarui standard este un inceput dar trebuie si
sa credeti in ele. Urmarea acestor standarde nu este ceva ce faceti cand aveti timp ci
trebuie sa fie ceva ce faceti intotdeauna deoarece credeti ca acesta este cel mai mod de
a scrie cod.
3. Urmati aceste standarde cand scrieti codul, nu dupa aceea. Respectarea acestor
standarde va conduce la cresterea productivitatii pe parcursul dezvoltarii si va face
codul dvs. mai usor de intretinut. Daca scrieti cod curat chiar de la inceput veti avea de
castigat in timp ce il creati.

12.3 Alti factori ce concura la scrierea unui cod de calitate

1. Programati pentru oameni nu pentru masini. Folositi conventiile pentru nume.

Documentati-va codul. Aliniati-va codul.
2. Proiectati intai, apoi scrieti codul. Daca veti aloca putin timp pentru a va gandi cum
veti scrie codul inainte de a incepe scrierea lui, probabil veti avea nevoie de mai putin
timp pentru a-l scrie.
3. Dezvoltati cu pasi mici. Dezvoltand in pasi mici, scriind una sau cateva metode,
testand si apoi scriind alte cateva metode este de cele mai multe ori mult mai eficient
decat sa scrieti toata bucata de cod odata si apoi sa o testati pe toata. Puteti depista un
bug mult mai repede intr-o sectiune de cod mica decat intr-una mare.
4. Cititi, cititi, cititi. …
5. Lucrati indeaproape cu utilizatorii dvs. …
6. Scrieti codul simplu. Scrierea de cod complicat poate aduce satisfactii intelectuale
celui care il scrie dar daca alti oameni nu il pot intelege, atunci nu este de nici un
folos. Urmati regula KISS : Keep It Simple, Stupid.

13
Inginerie Software

14