Bune Practici in

Programare

1. Introducere

In cele mai multe cazuri codul scris initial de un

programator va fi intretinut si dezvoltat in viitor de catre alti
programatori.
Un cod scris bine este considerat codul care va fi usor de
intretinut/modificat de alti programatori decat cel care a
scris codul.
Exista cazuri in care programatorii prefera sa rescrie
complet codul precedent, decat sa il modifice, deoarece
considera ca rescrierea le va ocupa mai putin timp decat
intelegerea codului si modificarea lui, de aici nevoia de a
scrie codul bine.

2. Bune practici in scrierea codului

2.1. Modularizare
2.2. Folosirea constantelor si a claselor de
constante
2.3. Comentarea codului
2.4. Declararea variabilelor in blocul de cod
unde sunt folosite
2.5. Initializarea variabilelor la declarare
2.6. Spatierea codului
2.7. Folosirea conventiilor de nume
2.8. Folosirea tipului private pe cat de mult
posibil

3. Bune practici in timpul dezvoltarii

3.1. Folosirea solutilor cele mai simple

3.2. Optimizarea codului
3.3. Identificarea erorilor in timpul scrierii
codului si nu la sfarsit
3.4. Folosirea debugului in depistarea erorilor si
nu alte metode
3.5. Refolosirea codului
3.6. Securizarea codului

2.1. Modularizare

Modularizarea reprezinta divizarea proiectului software in

module
Modularizarea permite o independenta conceptuala intre
module
Prin modularizare codul poate fi mai usor intretinut si se
pot adauga noi functionalitati noi nefiind nevoie de
modificari majore la codul deja existent
Modularizarea permite de asemenea refolosirea codului la
alte proiecte software

2.2. Folosirea constantelor si a claselor de

constante

Folosirea constantelor permite schimbarea unei valori

folosite in proiect mult mai repede, nefiind nevoie decat sa
modificam valoarea constantei
Folosirea constantelor scade riscul de a se produce greseli
de ortografie
Folosirea claselor de constante permite accesul mai rapid
si mai simplu la constantele folosite in proiect

2.3. Comentarea codului

Comentarea codului ar trebui scrisa odata cu scrierea

codului, fiind mult mai usor pentru programator sa descrie
codul la scurt timp dupa ce a fost scris
Comentarea codului va scade ulterior timpul necesar
programatorului pentru a intelege codul
Comentariile trebuie sa fie cat mai explicite, incercand sa
se evite comentariile la bucati de cod evidente (gen iterarea
cu 1 a unei valori)

2.4. Declararea variabilelor in blocul de cod

unde sunt folosite

Declararea variabilelor in blocul de cod unde sunt folosite

duce la un cod mai usor de inteles si vizualizat
Prin declararea variabilelor in blocul de cod unde sunt
folosite se evita folosirea gresita a acelei variabile si
rescrierea valorii inainte de blocul folosit

2.5. Initializarea variabilelor la declarare

Initializarea variabilelor atunci cand sunt declarate permite

evitarea anumitor erori (cum ar fi value may have not been
initialized)
Initializarea variabilelor in momentul declararii permite
programatorului sa aiba mai mult control asupra valorii
acelei variabile, stabilind o valoare default pentru acea
variabila

2.6. Spatierea codului

Spatierea codului reprezinta folosirea linilor albe (goale) si

a identarii linilor pentru o mai buna delimitare a codului
Cu ajutorul spatierii codului codul este mai usor de citit si
inteles de catre programator
Un cod nespatiat poate duce la un grad de oboseala a
programatorului mai mare intr-un timp mai scurt, scazand
capacitatea de lucru a acestuia

2.7. Folosirea conventiilor de nume

Folosirea conventiilor de nume ajuta la intelegerea mai

rapida a tipului sau rolului acelei entitati
Cateva reguli pentru alegerea numelor:
Constantele sa fie scrise cu majuscule, avand cuvintele
separate prin _
Variabilele sa aiba nume cat mai scurte posibil
NNumele metodelor sa inceapa cu un verb
umele claselor sa fie substantive
Toate numele sa fie cat mai sugestive posibil, permitand
intelegerea din nume a scopului acelei entitati

2.8. Folosirea tipului private pe cat de mult

posibil

Folosirea tipului private este recomandat datorita faptului

ca sporeste securitatea codului, spre exemplu nepermitand
modificari ilegale ale unor membri ai unei clase
De asemenea tipul private reduce riscul ca programatorul
sa modifice dintr-un modul extern valorile unor membri, a
caror valoare nu se doreste modificata

3.1. Folosirea solutilor cele mai simple

Este indicata folosirea solutilor mai simple, fata de cele

complexe, pentru a permite o intelegere mai usoara a
codului respectiv
De asemenea folosirea unei solutii mai simple scade riscul
aparitiei de erori sau cazuri particulare
O solutie simpla poate ajuta la optimizarea codului si
reducerea timpului de executie

3.2. Optimizarea codului

Desi optimizarea codului este foarte importanta pentru un

proiect software este de indicat ca acest pas sa fie facut
abia dupa ce s-a obtinut o varianta functionala a proiectului
Incercarea de optimizare a codului inca de la inceput duce
in multe cazuri la erori

3.3. Identificarea erorilor in timpul scrierii

codului si nu la sfarsit

Identificarea erorilor in timpul dezvoltarii codului permite de

multe ori rezolvarea acelei probleme fara prea mari
implicatii in restul codului
Solutionarea unei probleme la finalul dezvoltarii poate duce
la crearea de noi probleme, dependintele fiind mult mai
numeroase si complexe
De asemenea o problema identificata la sfarsitul proiectului
face mult mai grea depistarea bucatii de cod cu probleme

3.4. Folosirea debugului in depistarea erorilor

si nu alte metode

Este indicata folosirea sistemului de debug al limbajului in

defavoarea folosirii de alte metode precum comenzilor de
afisare (System.out.println, cout, print, echo) datorita
faptului ca permite identificarea erorii mai repede si mai
exact

3.5. Refolosirea codului

Daca o bucata de cod se repeta in cadrul proiectului

incercati sa incapsulati acel cod intr-o metoda pentru a
putea fi refolosit.
De asemenea scrierea codului pe module independente
permite programatorului sa refoloseasca acel modul de la
un proiect la altul
Este indicata refolosirea codului pe cat de mult posibil,
deoarece reduce timpul necesar proiectului si reduce riscul
de produceri de erori (odata ce avem un modul sigur este
indicata refolosirea lui deoarece rescrierea lui poate
provoca erori)

3.6. Securizarea codului

Codul trebuie scris in asa fel incat sa lase cat mai putin loc
de greseli
Pentru a avea un cod cat mai sigur sunt indicati urmatorii
pasi:
Testarea tuturor valorilor, chiar daca consideram ca nu are
cum sa aiba o anumita valoare
Folosirea tipului private pe cat de mult posibil
Procesarea inputului primit de la user, spre exemplu in cazul
unui input pentru o cautare folosing SQL acel input trebuie
procesat astfel incat sa nu permita SQL Injection
Asigurarea codului impotriva buclelor infinite