UNIVERZITET U NOVOM SADU

PRIRODNO-MATEMATIKI FAKULTET
DEPARTMAN ZA
MATEMATIKU I INFORMATIKU

Duan Vajagi

Stil programiranja i
samodokumentujui kod
- Diplomski rad -

Novi Sad, 2007.

Predgovor
Jezik kao sredstvo komunikacije izmeu dva ili vie korisnika
mora da bude dostupan svim njegovim korisnicima. Za komunikaciju
izmeu ljudi postoje prirodni jezici. Meutim, prirodni jezici nisu
podesni za predstavljanje i prenoenje pojedinih informacija. U nekim
sluajevima prirodni jezici su se pokazali kao nedovoljno odreeni, jer
doputaju vieznanost i nisu dovoljno precizni.
Programski jezici slue za komunikaciju izmeu oveka i
raunara pa moraju biti dostupni i oveku i raunaru. Jezik raunara je
mainski jezik, nerazumljiv i nepraktian za oveka, dok je s druge
strane govorni jezik neprihvatljiv za raunar. Programski jezici su
znatno razumljiviji za oveka od mainskih jezika.
Pod raunarskim programiranjem se obino podrazumeva
ovekova aktivnost usmerena ka reenju nekog konkretnog problema
na raunaru. Problem se obino reava konstrukcijom algoritma za
reenje problema, a algoritam se zapisuje posredstvom programskog
jezika. Programski jezik dakle predstavlja sredstvo namenjeno za
komunikaciju oveka i raunara, a slui za opis algoritma na nain
razumljiv raunaru. Program tada predstavlja jedan nain zapisa
algoritma: reenja postavljenog problema. Moemo generalizovati:
program je spisak instrukcija (komandi) kojima se raunaru saoptava
nain reavanja odreenog problema.
Definicija dobrog programa se menjala tokom godina
razvoja programskih jezika. U pionirskim danima programiranja i
programskih jezika, dobar program je bio onaj koji se brzo izvrava na
raunaru i troi malo memorije. U dananje vreme dobrim programom
se pre svega smatra program koji je lak za itanje, razumevanje i
odravanje od strane oveka (programera), a ubrzavanje programa
korienjem programerskih trikova postaje manje vano. U
meuvremenu je takoe postalo jasno da se programiranje sastoji od
od dve aktivnosti: razvoja i odravanja programa, pri emu se na
odravanje programa (menjanje, prilagoavanje, ispravljanje greaka)
utroi 90% vremena od ukupnog ivotnog ciklusa programa.
Danas se organizovanjem itavog procesa oko razvoja,
testiranja i odravanja programa, kao i kreiranjem odgovarajuih
alatki za podrku itavom tom procesu, bavi posebna disciplina
raunarskih nauka: softversko inenjerstvo (eng. software
engineering).
Ovaj rad predstavlja specifian spoj stilova programiranja
(naina na koji programeri zapisuju svoj kod), kao i softverskog
inenjerstva kao optije naune discipline u odnosu na samo
programiranje. Osnovna namena ovog rada je da programerima (kako
poetnicima tako i iskusnijim) predoi neke tehnike pisanja koda
nezavisne od programskog jezika, koje e sam kod uiniti
preglednijim, itljivijim i estetski lepim. U drugom delu rada, koji je
blii softverskom inenjerstvu opisane su osnove korienja
programskih alata pri samom kodiranju, kao i niz praktinih saveta i

preporuka o kojima treba voditi rauna prilikom realizacije softverskih

projekata.
Sledi kratak pregled poglavlja:
U glavi 1 su data osnovne tehnike i stilovi formatiranja koda,
kao i koncepti formatiranja kontrolnih struktura, pojedinanih naredbi,
rutina, fajlova i modula.
Potom je opisana dokumentacija, neophodna svakom
softverskom proizvodu, kao i preporuke, uputstva i tehnike za
efikasno komentarisanje programa u glavi 2.
Glava 3 je posveena opisu programerskih alata koji
predstavljaju neophodnu pomo programerima i smanjuju koliinu
vremena potrebnu za dizajn i konstruisanje softverskih projekata.
Uticaj veliine programa na konstrukciju softverskih projekata
kao i na produktivnost je ukratko opisana u glavi 4.
Glava 5 se bavi osnovama upravljanja konstrukcijom i
konfiguracijom softverskih projekata, procenom plana kao i metrikom
istih.
Na kraju, u glavi 6 je izvren pregled uraenog i istaknute
glavne prednosti ovog rada.
Hteo bih da se zahvalim svom mentoru dr. Mirjani Ivanovi na
strpljenju, savetima i vremenu odvojenom za ovaj rad, kao i
lanovima komisije dr. Zoranu Budimcu i dr. Draganu Mauloviu.
Ne mogu, a da ne spomenem i Zorana Putnika, koji je uvek dostupan i
tehnikom podrkom doprineo konanom zavretku ovog rada.
Posebno se zahvaljujem roditeljima, Grozdi i arku na podrci
koju su mi pruili i to su mi omoguili dovoljno prostora i vremena
pre svega, neophodnih za studiranje.

Novi Sad, novembar 2007

Duan Vajagi

Sadraj
Predgovor .................................................................................... 2
1. Uvod ......................................................................................... 6
1.1. Format i stil ........................................................................ 6
1.2 Osnove formatiranja ........................................................... 6
1.3 Tehnike formatiranja .......................................................... 9
1.3.1 Praznine ........................................................................ 9
1.3.2 Grupisanje .................................................................... 9
1.3.3. Prazne linije............................................................... 10
1.3.4 Poravnanje .................................................................. 10
1.3.5. Uvlaenje .................................................................. 10
1.3.6. Zagrade...................................................................... 10
1.4 Stilovi formatiranja ........................................................... 10
1.4.1 isti blokovi (Pure Blocks) ........................................ 10
1.4.2 Format kraja linije (Endline format) .......................... 11
1.4.3 Imitacija istog bloka (Emulating Pure Blocks) ........ 12
1.4.4. Begin-End kao granice bloka ................................... 13
1.4.5 Koji stil je najbolji? .................................................... 14
1.5 Formatiranje kontrolnih struktura ..................................... 15
1.5.1. Uvlaenje za begin-end par ....................................... 15
1.5.2. Dvostruko uvlaenje unutar para begin end.......... 15
1.5.3 Korienje praznih linija izmeu "pasusa" ................ 16
1.5.4. Formatiranje bloka koji se sastoji od jedne naredbe . 16
1.5.5 Formatiranje sloenih logikih izraza ........................ 17
1.5.6 Formatiranje GOTO naredbe ..................................... 17
1.6 Formatiranje pojedinanih naredbi ................................... 18
1.6.1 Korienje razmaka .................................................... 18
1.6.2 Korienje poravnanja................................................ 19
1.6.3 O duini naredbe ........................................................ 19
1.6.4 Formatiranje deklaracija podataka ............................. 23
1.7 Formatiranje komentara .................................................... 24
1.8 Formatiranje rutina ........................................................... 25
1.9 Formatiranje fajlova, modula i programa ......................... 28
2. SAMODOKUMENTUJUI KOD...................................... 33
2.1. Spoljna dokumenta .......................................................... 33
2.2. Programerski stil kao dokumentacija .............................. 33
2.3. Komentarisati ili ne? ........................................................ 34
2.4. Kljuevi za efektivne komentare ..................................... 34
2.4.1 Efikasno komentarisanje ............................................ 34
2.4.2. O stilovima komentarisanja ...................................... 35
2.4.3. Optimalan broj komentara ........................................ 36
2.5. Tehnike komentarisanja ................................................... 36
2.5.1 Komentarisanje individualnih linija ........................... 36
2.5.2 Endline komentari i problemi sa njima ...................... 37
4

2.5.3 Komentarisanje paragrafa koda ................................. 38

2.5.4 Komentarisanje deklaracija podataka ........................ 43
2.5.5 Komentarisanje kontrolnih struktura ......................... 45
2.5.6 Komentarisanje rutina ................................................ 46
2.5.7 Komentarisanje fajlova, modula i programa .............. 49
3. PROGRAMSKI ALATI ...................................................... 51
3.1 Alati dizajna ...................................................................... 51
3.2. Alati izvornog koda ......................................................... 51
3.3 Alati izvrnog koda ........................................................... 55
3.3.1 Formiranje koda ......................................................... 55
3.3.2 Podeavanje koda ....................................................... 56
3.4 Alatno-orijentisano okruenje .......................................... 57
3.5 Pravljenje sopstvenog alata za programiranje .................. 58
3.6 Idealno programsko okruenje ......................................... 58
4. UTICAJ VELIINE PROGRAMA NA KONSTRUKCIJU
SOFTVERSKIH PROJEKATA ........................................ 61
4.1. Radijus veliina projekta ................................................. 61
VELIINA TIMA............................................................... 61
4.2. Uticaj veliine projekta na razvojne aktivnosti ............... 62
4.2.1 Komunikacija i veliina ............................................. 62
4.2.2 Proporcija aktivnosti i veliina .................................. 63
4.2.3 Metodologija i veliina .............................................. 64
4.2.4 Programi, proizvodi, sistemi i sistemski proizvodi .... 66
4.3. Efekat veliine projekta na greke ................................... 66
4.4. Efekat veliine projekta na produktivnost ....................... 67
5. UPRAVLJANJE KONSTRUKCIJOM SOFTVERSKIH
PROJEKATA ...................................................................... 69
5.1 Ohrabrivanje dobrog kodiranja ......................................... 69
5.1.1 Tehnike poveanja efikasnosti programiranja ........... 69
5.2. Upravljanje konfiguracijom softverskih projekata .......... 70
5.2.1 ta je upravljanje konfiguracijom? ............................ 70
5.2.2 Promene u dizajnu softvera ........................................ 70
5.2.3 Promene u kodu softvera............................................ 71
5.3. Procena plana konstrukcije softverskih projekata ........... 72
5.3.1 Prilaz proceni ............................................................. 73
5.3.2 Uticaj na plan ............................................................. 73
5.3.3 Procena vs kontrola .................................................... 74
5.3.4 ta ako kasnite? .......................................................... 74
5.4. Metrika ............................................................................. 74
5.5. I programeri su ljudi ........................................................ 76
5.6. Kontroliite svog menadera ........................................... 79
6.0. ZAKLJUAK .................................................................... 81
LITERATURA ......................................................................... 83

1. Uvod
U ovom poglavlju obratiemo panju na estetsku komponentu
programiranja tj. planiranja i projektovanja izgleda tj. formata
izvornog koda. Cilj je da objasnimo neka od osnovnih pravila
zapisivanja izvornog koda programa tako da mi kao "pisci" budemo
zadovoljni njegovim izgledom i strukturom, a da sam kod bude lako
itljiv kako strunjacima tako i (manje-vie) poetnicima u
programiranju.

1.1. Format i stil

Dakle, ne bavimo se korienjem resursa raunara (brzina
izvravanja, korienje memorije itd.), ve iskljuivo tehnikama i
metodama koji e omoguiti da kod bude itljiv, razumljiv, lak za
pregledanje i ispravljanje, ak i mesecima kasnije, kad ve
zaboravimo da smo ga i pisali. Iskustvo nam govori da postoji puno
detalja, koji su zapravo sastavni deo koda, na koje moramo obratiti
panju upravo u toku samog pisanja izvornog koda, bez obzira to se
esto ini da je to gubljenje.
Ko god je radio ne nekom iole ozbiljnijem projektu ili u okviru
tima, shvata znaaj ove teme.
Uputstva koja slede, naravno nisu obavezna, i mnogima se
verovatno nee svideti, ali su preporuljiva i ine deo "programerske
higijene" koju e prepoznati svaki iskusniji programer, profesor,
predava ili IT manager od kojih na kraju krajeva zavisi poloeni ispit
ili dobitak (gubitak) posla.

1.2 Osnove formatiranja

Pogledajmo sledei primer:
procedure InsertionSort(Var: Data: SortArray_t; FirstElmt: Integer;
LastElmt: Integer ); { Use the insertion sort tehnique to sort the "Data" array
in ascending order. This routine assumes that Data [FirstElmt] is not the
FirstElmt element in Data and that Data [FirstElmt-1] can be accessed. }
Const SortMin =' '; Var SortBoundary: Integer; {upper end of sorted range}
InsertPos: Integer {position to insert element} InsertVal: SortElmt_t; {value to
insert} LowerBoundary: SortElmt_t;
{first value below range to sort} begin {Replace element at lower boundary
with an element guaranteed to be first in sorted list} Lower Boundary := Data[
FirstElmt-1]; Data [FirstElemt-1] := SortMin; { The elements in position
FirstElmt through SortBoundary-1 are always sorted. In ich pass through the
loop, SortBoundary is increased, and the element at positionof the new
SortBoundary probably isn't in its sorted place in the array, so it's inserted
into the proper place somewhare between FirstElmt and SortBoundary. } for
SortBoundary := FirstElmt +1 to LastElmt do begin InsertVal := Data
[SortBoundary]; InsertPos :=SortBoundary; while InsertVal < Data [InsertPos1] do begin Data[InsertPos] := Data[InsertPos-1]; InsertPos := InsertPos-1;
end; Data [InsertPos] :=InsertVal; end; {replace original lower-boundary
element} Data[ FirstElmt-1]:=LowerBoundary;end; {InsertionSort}

Primer 1. Procedura za sortiranje elemenata niza

6

Bez obzira to je gornji kod napisan u programskom jeziku

Pascal sintaksno i logiki taan (ko ne veruje neka ga testira), ovo je
tipian primer pisanja neitkog i nerazumljivog programa koji nema
nikakvu preglednu strukturu niti raspored koda. ta treba da uinimo
pa da dati kod bude prihvatljiviji?
U narednom primeru dato je jedno mogue, mada ne i
dovoljno poboljanje koda:
procedure InsertionSort(Var: Data: SortArray_t; FirstElmt: Integer;
LastElmt: Integer );
{ Use the insertion sort tehnique to sort the "Data" array in ascending order.
This routine assumes that Data [FirstElmt] is not the FirstElmt element in
Data and that Data [FirstElmt-1] can be accessed. }
Const
SortMin =' ';
Var
SortBoundary: Integer; {upper end of sorted range}
InsertPos: Integer {position to insert element}
InsertVal: SortElmt_t; {value to insert}
LowerBoundary: SortElmt_t; {first value below range to sort}
begin
{Replace element at lower boundary with an element guaranteed to be first in
sorted list}
Lower Boundary := Data[ FirstElmt-1];
Data [FirstElemt-1] := SortMin;
{ The elements in position FirstElmt through SortBoundary-1 are always
sorted. In ich pass through the loop, SortBoundary is increased, and the
element at positionof the new SortBoundary probably isn't in its sorted place
in the array, so it's inserted into the proper place somewhare between
FirstElmt and SortBoundary. }
for SortBoundary := FirstElmt +1 to LastElmt do
begin
InsertVal := Data [SortBoundary];
InsertPos :=SortBoundary;
while InsertVal < Data [InsertPos-1] do
begin Data[InsertPos] := Data[InsertPos-1];
InsertPos := InsertPos-1;
end;
Data [InsertPos] :=InsertVal;
end;
{replace original lower-boundary element}
Data[ FirstElmt-1] :=LowerBoundary;
end; {InsertionSort}

Primer 2. Vizuelno poboljanje procedure iz prethodnog primera

Iako kod jo uvek nije preterano itljiv, u svakom sluaju je

bolje vizuelno struktuiran i prirodniji od koda iz prvog primera.
Logike celine koda su relativno odvojene (deklaracija konstanti,
promenljivih, telo programa) ali je kod jo uvek "stinjen", "zgusnut" i
kompjuter e ga lako razumeti (kao uostalom i prethodni primer), ali

je i dalje prilino neitljiv. Idemo korak dalje u popravljanju formata

tj. izgleda polaznog koda:
procedure InsertionSort
(
Var: Data:
SortArray_t;
FirstElmt:
Integer;
LastElmt:
Integer
);
{ Use the insertion sort tehnique to sort the "Data" array in ascending order. This
routine assumes that Data [FirstElmt] is not the FirstElmt element in Data and that
Data [FirstElmt-1] can be accessed. }
Const
SortMin =' ';
Var
SortBoundary:
InsertPos:
InsertVal:
LowerBoundary:

Integer;
Integer
SortElmt_t;
SortElmt_t;

{upper end of sorted range}

{position to insert element}
{value to insert}
{first value below range to sort}

begin
{ Replace element at lower boundary with an element guaranteed to be
first in sorted list}
Lower Boundary := Data[ FirstElmt-1];
Data [FirstElemt-1] := SortMin;
{ The elements in position FirstElmt through SortBoundary-1 are always
sorted. In ich pass through the loop, SortBoundary is increased, and the
element at positionof the new SortBoundary probably isn't in its sorted
place in the array, so it's inserted into the proper place somewhare
between FirstElmt and SortBoundary. }
for SortBoundary := FirstElmt +1 to LastElmt do
begin
InsertVal := Data [SortBoundary];
InsertPos :=SortBoundary;
while InsertVal < Data [InsertPos-1] do
begin
Data[InsertPos] := Data[InsertPos-1];
InsertPos := InsertPos-1;
end;
Data [InsertPos] :=InsertVal;
end;
{replace original lower-boundary element}
Data[ FirstElmt-1] :=LowerBoundary;
end; {InsertionSort}

Primer 3. Konana verzija polazne procedure

Uporedimo sada polazni i ovaj primer pisanja koda. Iako je

sintaksa i logika koda u sva tri primera ista, trei primer je vizuelno
neuporedivo pregledniji, logike strukture programa su odvojene i
itljive, komentari poravnati i uvueni, a kompjuteru je svakako
svejedno da li smo mu prosledili prvi, drugi ili trei primer koda.
Posao popravljanja i vizuelnog poboljavanja koda se zapravo
sveo na to da se koriste prazni karakteri, prazni redovi i uvlaenje
logikih celina koda tzv. nazubljenje. Kod izgleda relativno lepo, a i
logika struktura programa je lako uoljiva.

REZIME:
to se tie strukture i rasporeda tj. formata samog koda isti cilj
se moe postii na vie naina, ali je bitno da kada se odluite za jedan
nain, da se njega drite do kraja pisanja programa. Ukratko, ciljevi su
sledei:
a) precizno i dosledno prikazati logiku strukturu koda (veina
programera koristi praznine i nazubljenja tj. uvlaenja
pojedinih redova, da bi logike celine bile uoljivije)
b) poboljanje itljivost programa je prioritet
c) struktura koda mora biti laka za pregledanje i naravno kasnije
odravanje
Dakle jedno od osnovnih pravila je:
PIITE PROGRAME TAKO DA SU RAZUMLJIVI I ITLJIVI
PRVO LJUDIMA, PA TEK ONDA KOMPJUTERIMA

1.3 Tehnike formatiranja

U ovom poglavlju e biti opisano nekoliko najee korienih
tehnika (koje se mogu koristiti na razliite naine) da bi kod bio
vizuelno bolje struktuiran: dobro isplaniran, itljiv, razumljiv, sa lako
vidljivom logikom strukturom.

1.3.1 Praznine
Predstavljaju glavne alate za prikazivanje programske strukture
(razmaci, tabulatori, prazne linije); pomou njih odvajamo pojedine
celine koda slino kao to su i knjige podeljene na poglavlja, pasuse,
reenice.

1.3.2 Grupisanje
Direktno je povezano sa prazninama i to tako to instrukcije
koda koje ine jednu celinu treba da budu grupisane jednakim
uvlaenjem.

1.3.3. Prazne linije

Pomou njih odvajamo instrukcije koje su u razliitim
grupama, kao i eventualne komentara koda.

1.3.4 Poravnanje
Treba poravnati sve objekte tj. elemente koji po definiciji ine
smislenu celinu, npr. znak jednakosti prilikom naredbe dodeljivanja
vrednosti, ili otvorenu i zatvorenu zagradu prilikom pisanja komentara
itd; u kombinaciji sa prazninama i grupisanjem poveava se itljivost
programa i logike celine samog koda.

1.3.5. Uvlaenje
Posebno interesantno za prikazivanje logike strukture koda, u
praksi se popularno zove i nazubljenje; grupa naredbi (koja ini
celinu) mora tj. treba da bude isto nazubljena iliti uvuena, a ako
postoji "ugnjedena" podgrupa ona bi trebalo da se uvue jo udesno i
tako oslika logiku celinu koda.

1.3.6. Zagrade
Upotreba zagrada se esto preporuuje, a naroito kada imate
izraz sainjen od vie podizraza, jer nikad ne znate kako pojedini
prevodioci tretiraju i izraunavaju izraze. Posmatrajmo sledee
primere u okjima su izostavljene zagrade. Izrazi su napisani u
programski jezicima C, Pascal i Basic redom.
12+4%3*7/8
12+4mod3*7div8
12*mod3*7/8
Primer 4. Razliiti izrazi bez upotreba zagrada

Da biste izraunali vrednost ovih izraza potrebno je prilino

razmiljanja.

1.4 Stilovi formatiranja

U razliitim programskim jezicima koriste se razliiti abloni
za grupisanje naredbi unutar kontrolnih struktura kako bi kod
programa bio pregledniji (npr. begin i end u Pascalu ili / i / u C-u).
etiri standardna stila su:

1.4.1 isti blokovi (Pure Blocks)

Svaki dobro dizajnirani programski jezik ima tano definisanu
strukturu blokova i obinim uvlaenjem naredbi koje ine blok unutar
kontrolnih struktura stiemo do eljenog rezultata. Pogledajmo sledei
primer:
10

if PixelColor = RedColor then

statement 1
statement 2
...
end if;

while PixelColor = RedColor loop

statement 1
statement 2
...
end loop;

Primer 5. Upotreba istih blokova

Uokvireni primeri su napisani u programskom jeziku Ada, a i

neki drugi jezici podravaju ovakvu logiku. Naime, svaka kontrolna
struktura ima poetak i kraj naredbe (if then - end if, while loop - end
loop), a unutar nje je jedna ili vie naredbi, uvuena i ini razumljiv i
itljiv skup naredbi, dakle potpuni blok. U optem sluaju struktura
naredbe bloka je prikazana na sledeoj slici:
A.
B.
C.
D.

Slika 1. Opti sluaj upotrebe istih blokova

Jasno je da su naredbe A i D poetna i krajnja naredba

kontrolne strukture, a unutranje naredbe (B i C u ovom sluaju) ine
blok naredbi unutar strukture.
Kod ovakve strukture pisanja koda, postoji problem kod nekih
programskih jezika koji nemaju "istu" blokovsku strukturu pa
programeri mogu biti u nedoumici da li i kada blokove odvajati sa
recimo begin i end, a kada to nije neophodno. Odvajanje blokova na
ovakav nain i korienje uvlaenja je najee problem kod loije
dizajniranih jezika.

1.4.2 Format kraja linije (Endline format)

Evo jednog od naina da "doskoimo" pisanju programa u
jezicima koji eksplicitno ne zahtevaju "istu" blokovsku strukturu, a
da ipak napiemo pregledan i itljiv kod. Ideja je da se kljuna re
naredbe tj. prva naredba kontrolne strukture pie od poetka reda, a
blok naredbi koje ini telo strukture je uvuen udesno tako da se svaka
instrukcija koja ini blok pie jedna ispod druge i to uvuena za isti
broj praznina. Struktura opte naredbe napisana u formatu kraja linije
data je na sledeoj slici:

11

A.
B.
C.
D.

Slika 2. Opti sluaj upotrebe formata kraja linije

Jasno je da su A i D naredbe za poetak i kraj kontrolne

strukture respektivno, a B i C ine telo ove naredbe. Instrukcije iz tela
naredbe su poravnate sa naredbom koja otpoinje blok i nalazi se u
istom redu gde je i naredba za poetak kontrolne strukture. Istim
brojem praznina uvlaenja za naredbe B,C i D treba jednostavno da se
vizuelno pokae grupisanje ove naredbe u jedan blok.
U ovom primeru su naredbe napisane u programskom jeziku Pascal u
formatu kraja linije:
if ( SoldCount >1000) then begin
Markdown :=0.10;
Profit
:=0.05;
end;
else Markdown :=0.05
while PixelColor = RedColor do begin
statement 1
statement 2
...
end;
Primer 6. Upotreba formata kraja linije u Pascal - u

Meutim postoji i odgovarajui problem. Naime, u sluaju

kada imamo vie ugnjedenih kontrolnih struktura tj. ispitivanja
uslova jedan u drugom koristei ovaj stil lako se vizuelno izgubi
logika struktura i sam kod postaje neitljiv i nepregledan. Dakle, pri
svakom ispitivanju sloenijih uslova striktno korienje ovakvog stila
nam nee dati eljene rezultate.

1.4.3 Imitacija istog bloka (Emulating Pure

Blocks)
Prilikom korienja ovakve sheme pisanja koda, blokove
odvajamo sa slubenim reima begin i end, s tim to se re begin pie
u prvom redu, dakle na kraju prve naredbe kontrolne strukture, a re

12

end se nalazi kao poslednja naredba kontrolne strukture. Na slici 3

prikazan je opti izgled naredbe napisane u ovom formatu:
A.

prva naredba

begin

B.

druga naredba

C.

ostale naredbe

D.

end

Slika 3. Opti oblik naredbi zapisanih u formatu imitacije istog bloka

U ovom primeru su date dve naredbe zapisane u ovom formatu:

if PixelColor = RedColor then begin
statement 1
statement 2
...
end;

while PixelColor = RedColor do begin

statement 1
statement 2
...
end;
Primer 7. Upotreba imitacije istog bloka u Pascal-u

Ovakav raspored pisanja koda je primenljiv u veini

programskih jezika, pregledan je i jasno prikazuje logiku strukturu
napisanog koda. Ugodan je za korienje i vrlo esto se preporuuje za
praktinu primenu.

1.4.4. Begin-End kao granice bloka

U ovom formatu pisanja koda koristi se par naredbi begin-end
da bi odvojili blok instrukcija koje ine neku logiku celinu. U
principu, slino je strukturi pisanja koda kod tzv. "istih" blokova to
je na optem sluaju prikazano na slici 4:

13

A.

strukture
begin

B.
C.
end

Slika 4. Opti oblik naredbe zapisane u formatu begin end kao

granica bloka

Dakle, par begin-end nam slui kao "granica" tj. poetak i kraj
bloka naredbi koje ine telo kontrolne strukture koja poinje
naredbom A. U primeru 8 su navedena dva konkretna primera naredbi
koje ilustruju ovaj format:
if PixelColor = RedColor then
begin
statement 1
statement 2
...
end;

while PixelColor = RedColor do

begin
statement 1
statement 2
...
end;
Primer 8. Upotreba para begin end u Pascal-u

Ovakav nain uvlaenja je prilino pregledan, a i logika

struktura samih naredbi je oigledna tako da je ovakav raspored
pisanja koda prihvatjiv u veini programskih jezika.

1.4.5 Koji stil je najbolji?

Teko je odgovoriti koji od navedenih stilova je najbolji.
injenica je da je endline stil loiji od ostalih iz prostog razloga to ga
je teko dosledno primenjivati, a i nezgodan je za kasnije odravanje
koda.
Naime, nijedan od nabrojanih stilova pisanja koda nije potpuno
primenljiv, siguran, zatien za univerzalnu primenu pri programiranju
u bilo kom programskom jeziku i izbor pojedinog stila zavisi
14

prvenstveno od programskog jezika u kome se radi, kao i od linih

estetskih kriterijuma samog programera. Naravno, kompromisi stilova
su uvek mogui, no vano je rei da kada jednom odaberemo stil i
dosledno ga primenjujemo biemo zadovoljni vizuelnim izgledom
programa, a i bilo ko ko doe u dodir sa kodom odmah e uvideti da je
to pisao neko ko je programerski obrazovan.

1.5 Formatiranje kontrolnih struktura

Struktura i raspored pisanja pojedinih delova programa u
veini sluajeva je isto estetske prirode, ali shema pisanja koda
kontrolnih struktura bitno utie na itljivost i razumljivost programa i
zato nam mora biti prioritet. Evo nekoliko kratkih uputstava koje bi
trebalo slediti sa svim njihovim dobrim i loim stranama:

1.5.1. Uvlaenje za begin-end par

Ako ovo ne potujemo, kao to se vidi u sledeem primeru,
jednostavno naruava se logika struktura samog koda jer ne vidimo
gde zapravo pripadaju naredbe unutar bloka begin-end: da li samoj
kontrolnoj strukturi ili su jednostavno samostalne. U ovom primeru je
dobro napisana for naredba:
for i := 1 to MaxLines do
begin
ReadLine( i )
ProcessLine( i );
end;

Primer 9. Pogrena upotreba para begin end i kontrolne strukture

Poetak bloka tj. naredba begin kao i kraj bloka tj. naredba
end su poravnate sa for naredbom koja je u stvari njihova kontrolna
struktura, a ovde se vizuelno ne vidi da je blok naredbi logika celina
unutar same kontrolne strukture i da se uopte odnosi na nju.

1.5.2. Dvostruko uvlaenje unutar para

begin end
Potrebno ga je izbegavati. Za prikazivanje logike strukture
programa dovoljno je samo uvui par begin-end, ali je bespotrebno
uvlaiti i naredbe unutar tog para jer ne poboljavaju itljivist i
preglednost programa; naime, ako imate nekoliko ugnjedenih naredbi
i koristite dvostruko uvlaenje dobijate minimum 4-6
nivoa
uvlaenja, a to je priznaete tee za praenje. Na slici 5 se vidi nain
uvlaenja koji se preporuuje za optu kontrolnu strukturu:

15

kontrolna struktura
begin

end

Slika 5. Opti oblik pravilnog uvlaenja para begin - end

1.5.3 Korienje praznih linija izmeu "pasusa"

Naredbu kontrolne strukture kao i njoj odgovarajui blok
naredbi moemo posmatrati kao pasuse u obinom tekstu; takoe
postoje i naredbe koje nisu odvojene parom begin-end i ne pripadaju
nekoj od kontrolnih struktura ali ipak ine jednu celinu; preporuka je
da ovakve grupe naredbi odvajamo jednom praznom linijom.
Window.Dimension
Window.Title
Window.Background.Color

= EditWindow.Dimensions;
= EditWindow.Title;
= UserPreferences.BackgroundColor;

Cursor.Start
= StartingScanLine;
Cursor.End
= EndingScanLine;
Cursor.BlinkRate
= EditMode.BlinkRate;
SaveCursor ( Cursor );
SetCursor ( Cursor );

Primer 10. Upotreba prazne linije izmeu pasusa

1.5.4. Formatiranje bloka koji se sastoji od

jedne naredbe
Potrebno ih je formatirati uvek na isti nain. Ovakvi blokovi
nastaju kada naredbu kontrolne strukture (if, case, for...) sledi samo
jedna naredba. Ima nekoliko naina da se ovaj problem adekvatno rei
i svaki od njih ima svoje prednosti i mane. U primeru 11 dato je
nekoliko naina formatiranja ovakvog bloka:
if (expression) then
one-statement;

if (expression) then begin

one-statement
end;

16

if (expression) then
begin
one-statement
end;

if (expression) then one-statement;

Primer 11. Naini formatiranja bloka koji se sastoji od jedne
naredbe

Bez obzira koji od naina navedenih u primeru 11 odaberete, dosledno

ga koristite za svaku naredbu IF, CASE, ...

1.5.5 Formatiranje sloenih logikih izraza

Kod sloenih logikih izraza potrebno je svaki uslov pisati u
posebnoj liniji. Kada program pie poetnik koji ne vodi rauna o
itljivosti programa i o ljudima koji e njegov program kasnije itati
i/ili ispravljati onda to vrlo esto moe da izgleda kao u primeru 12:
if (( '0' <= InChar and InChar <='9') or ('a' <= InChar and
InChar <='z') or ('A' <= InChar and InChar<= 'Z')) then
...

Primer 12. Neitko formatiranje sloenog logikog izraza

Meutim, uz malo truda i formatiranja ovog koda dobijamo

prihvatljiviji kod to se vidi iz primera 13:
if ( ( '0' <= InChar and InChar <='9' ) or
( 'a' <= InChar and InChar <= 'z' ) or
( 'A' <= InChar and InChar<= 'Z' ) ) then
...
Primer 13. Poboljanje koda iz prethodnog primera

Dakle, svaki od uslova sloenog izraza se zapisuje u novoj

liniji, uvlai se i poravnava i tako dobijamo itljiv i razumljiv kod lak
za pregled i modifikaciju.

1.5.6 Formatiranje GOTO naredbe

Opte je poznato da su programi bez GOTO naredbe
kvalitetniji i da je lake pratiti tok izvravanja programa bez ove
naredbe. Meutim ako koristite GOTO naredbu prilikom formatiranja
moete imati velikih problema, a evo nekoliko saveta koji to mogu
preduprediti:

17

a) koristite velika slova za oznaavanje labela na koje "skae"

naredba GOTO
b) GOTO naredbu uvek piite u posebnom redu
c) labelu na koju "skae" GOTO naredba takoe piite u
posebnom redu i to okruenu praznim redovima tako da bude
uoljiva

1.6 Formatiranje pojedinanih naredbi

U ovom delu naveemo nekoliko korisnih saveta za
poboljanje izgleda pojedinanih naredbi prilikom pisanja programa.

1.6.1 Korienje razmaka

Koristite razmake zbog poboljanja itljivosti naredbe.Evo
nekoliko standardnih situacija kada adekvatno korienje razmaka
uveliko pomae da naredba bude jasnija i razumljivija itaocu:
a) kod logikih izraza da odvojite razliite identifikatore i
poboljate itljivost: Poetnici to ne rade to se vidi iz
primera 14:
while(PathName[StartPath+Pos]<>';') and
((StartPath+Pos)<=length(PathName)) do

Primer 14. Primer logikog izraza bez upotrebe razmaka

Potujui prethodne savete imamo bolji kod dat u primeru 15

while ( PathName[ StartPath+Pos ] <> ';') and
( ( StartPath + Pos ) <= length(PathName)) do

Primer 15. Primer logikog izraza sa upotrebom razmaka

b) prilikom korienja nizova: Ideja je da svaki indeks, tj.

referencu indeksa u nizu koji koristimo odvojimo razmakom
da bi bio uoljiviji; ako koristimo ovaj savet dobijamo sledei
kod dat u primeru 16:
GrossRate[ Census[ GroupId ].Sex, Census[ GroupId ]. AgeGroup

Primer 16. Formatiranje reference niza upotrebom razmaka

Zamislite kako bi prethodna naredba izgledala bez razmaka i

izbegavajte takav nain pisanja naredbi.

18

c) da bi odvojili argumente rutina koje koristite: Primer 17

pokazuje kako izgleda naredba za poziv rutine bez upotrebe
razmaka, a primer 18 predstavlja poboljanje korienjem
prethodnog saveta
ReadEmployeeData(MaxEmps,EmpData,InputFile,EmpCount,InputError)
Primer 17. Formatiranje poziva rutine bez korienja razmaka
ReadEmployeeData( MaxEmps, EmpData, InputFile, EmpCount, InputError )
Primer 18. Formatiranje poziva rutine korienjem razmaka

1.6.2 Korienje poravnanja

Koristite poravnanje u grupama naredbi dodeljivanja vrednosti.
Ova smernica se odnosi na poravnanje znaka jednakosti kod grupe
naredbi koje ine jednu logiku celinu. Naredni primeri ilustruju
primenu ovog zahteva
EmployeeName
EmployeeAdress
EmployeePhone
BossTitle
BossTitle

=
=
=
=
=

InputName
InputAdress
InputPhone
Title
Department

Primer 19. Poravnanje znaka jednakosti kod naredbi dodele

vrednosti

EmployeeName = InputName
EmployeeAdress = InputAdress
EmployeePhone = InputPhone
BossTitle = Title
BossTitle = Department
Primer 20. Razdvajanje logikih blokova upotrebom prazne linije
Poravnanje nije sporno, ali u primeru 19 praktino imamo dva
logika bloka i to: podatke o zaposlenima i o njihovim efovima pa bi
bilo mnogo lepe da to zapiemo kao u primeru 20.
Na ovaj nain, samo smo pokazali razliku izmeu izmeu
akcija sa zaposlenima i efovima odvajajui ih prazom linijom i
koristei razliito poravnanje znaka jednakosti.

1.6.3 O duini naredbe

Duina jedne instrukcije ne bi trebalo da prelazi 80 karaktera i
to iz bar jednog od sledeih razloga: due naredbe su teke za itanje i
19

praenje, ne staju u jedan red papira standardnog formata, a i

"ugnjedavaje" ovako dugakih naredbi je potpuno obeshrabrujue.
Prilikom programiranja esto imamo situaciju da je
programska linija fiziki predugaka da bi stala u jedan red, ili je pak
neitko i nerazumljivo da je tako piemo. Tada smo prisiljeni da
ostatak naredbe piemo u novom redu. U nastavku je navedeno
nekoliko praktiih saveta i preporuka za reavanje ovog problema.
a) kraj prvog reda ovakve naredbe mora biti uoljiv
Najprirodnije je da naredbu koja ve ne moe da stane u jedan
red "prelomimo" tako da bude jasno i uoljivo da je to samo
deo naredbe i da se ona nastavlja u novom redu.
while (PathName[ StartPath + Pos ] <> ';' ) and
( ( StartPath + Pos ) <= length( PathName ) ) do
...
Primer 21. Prelamanje dugake naredbe slubenom rei and
TotalBill := TotalBill + CustomerPurchases[ CustomerID ] +
SalesTax( CustomerPurchases[ CustomerID ] );
...

Primer

22.

Prelamanje
operatora +

dugake

naredbe

upotrebom

U Primeru 21 vidimo da je prvi deo naredbe zavren

slubenom rei and, koja jasno signalizira da naredba nije
zavrena.
U Primeru 22 smo koristili znak + da bi naglasili da je naredba
nekompletna i da se nastavlja u novom redu. Na slian nain
moemo koristiti i druge aritmetike i logike operatore kao i
recimo znak , (zarez) i slino.
b) vodite rauna o grupisanju srodnih elemenata: Dakle,
reference lanova niza, argumente pojedinih rutina (procedura,
funkcija, modula...) treba pisati u jednom redu.
CostumerBill := PrevBalance( PaymentHistory[ CostumerID ] ) +
LateCharge( PaymentHistory[ CostumerID ] );

Primer 23. Formatiranje referenci lanova niza

Pored toga to smo reference lanova niza odvojili u posebne

redove, koristili smo i njihovo poravnanje i svako drugo
formatiranje ove naredbe, osim gore navedenog, bilo bi
neitko i nepregledno.

20

c) ako je poziv rutina ovakva naredba, koristite standardno

uvlaenje: Prilikom poziva procedura, funkcija i drugih rutina
koje su nepotpune naredbe (dakle naredbe koje piemo u vie
redova) koristimo standardno uvlaenje (recimo tri prazna
mesta) kao i kod programskih petlji, IF, CASE i ostalih
naredbi... Primer 24 to najbolje ilustruje:
DrawLine( Window.North, Window.South, Window.East, Window.West,
CurrentWidth, CurrentAttribute );
SetFontAttributes( Font.FaceName, FontSize, Font.Bold, Font.Italic,
Font.SyntheticAttribute[ FontID ].Underline,
Font.Synthetic.Atribute[ FontID ].Strikeout );

Primer 24. Upotreba praznina kod dugakih naredbi za poziv rutine

Drugi nain da se ovo rei je da se prilikom poziva rutina,

nastavak naredbe koji prelazi u novi red poravna tako da bude
u koloni sa prvim argumentom poziva same rutine to se i vidi
iz primera 25:
DrawLine( Window.North, Window.South, Window.East, Window.West,
CurrentWidth, CurrentAttribute );
SetFontAttributes( Font.FaceName, FontSize, Font.Bold, Font.Italic,
Font.SyntheticAttribute[ FontID ].Underline,
Font.Synthetic.Atribute[ FontID ].Strikeout );

Primer 25. Upotreba poravnanja kod dugakih naredbi za poziv rutine

Koji ete od ova dva naina koristiti svejedno je i stvar je

linog ukusa i afiniteta.
d) kod ovakvih naredbi obezbedite da je kraj naredbe uoljiv
Problem je to je esto teko uoiti gde se ovakve naredbe
zavravaju, pa praenje i samog koda moe biti veoma
naporno, a modifikacija podlona grekama. Najbezbedniji
nain da se ovo rei je da npr. svaki argument piemo u novom
redu, a isto tako i otvorenu zagradu kao poetak i zatvorenu
zagradu kao kraj naredbe. U primeru 26 je ilustrovana upotreba
ovog pravila.

21

DrawLine
(
Window.North,
Window.South,
Window.East,
Window.West,
CurrentWidth,
CurrentAttribute
);
SetFontAttributes
(
Font.FaceName,
FontSize,
Font.Bold,
Font.Italic,
Font.SyntheticAttribute[ FontID ].Underline,
Font.Synthetic.Atribute[ FontID ].Strikeout
);

Primer 26. Primer formatiranja kraja dugake naredbe

e) ako su kontrolne strukture ovakve naredbe koristite

standardno uvlaenje: Pravila su potpuno ista kao i kod
poziva rutina, a kod sloenih logikih uslova koristimo i gore
pomenuta pravila za zapisivanje argumenata rutina
f) kod naredbi dodele poravnajte sledei red posle operatora
dodele: Ova preporuka je ilustrovana sa dva primera:
CustumerPurchases
CustomerBill
TotalCustomerBill
LateCharge(

:= CustumerPurchases + CustumerSales( CostumerID );

:= CustomerBill + CustomerPurchases
:= CustomerBill + PreviousBalance( CistomerID ) +
CustomerID );

Primer 27. Nepravilno formatiranje dugake naredbe dodele

CustumerPurchases := CustumerPurchases + CustumerSales( CostumerID );
CustomerBill
:= CustomerBill + CustomerPurchases
TotalCustomerBill
:= CustomerBill + PreviousBalance( CistomerID ) +
LateCharge( CustomerID );

Primer 28. Pravilno formatiranje dugake naredbe dodele

U primeru 27 je prikazano kako ne treba raditi:Ako, meutim,

dosledno primenimo prethodne preporuke dobijamo kod kao u
primeru 28.

22

g) koristite samo jednu naredbu po liniji: Iako svi moderniji

programski jezici dozvoljavaju da se nekoliko naredbi piu u
istom u redu, naravno uz odgovarajue separatore naredbi, iako
na taj nain moete u jednom trenutku videti vie koda vaeg
programa bilo na monitoru ili papiru evo nekoliko validnih
razloga zato se treba drati navedenog:
sloenost programa je uoljivija
pisanjem vie naredbi u jednoj liniji ne poboljava
prevoenje i optimizaciju koda
pregledanje koda je jednostavnije, dakle itamo samo od
gore na dole, a ne istovremeno i od gore na dole i sleva na
desno jer neka linija sadri vie od jedne naredbe
lake se pronalaze greke kada nam kompajler prijavi broj
linije u kojoj smo pogreili jer je svaka linija u posebnom
redu

1.6.4 Formatiranje deklaracija podataka

Prilikom formatiranja deklaracija podataka, itljivost programa
se moe poboljati korienjem sledeih saveta:
a) koristite poravnanje prilikom deklarisanja: U zavisnosti od
programa koji koristite za programiranje nekada se tipovi
podataka nalaze na desnoj strani, a nekad nazivi promenljivih.
No poto su sve deklaracije usko povezane poravnanje nam
omoguava da brzo i efikasno pregledamo tipove podataka i
nazive promenljivih bez obzira na kojoj se strani nalaze. U
primerima 29a i 29b su data dva sluaja ovog pravila.
SortBoundary:
Integer
InsertPos:
Integer
InsertVal:
SORT_STRING
LowerBoundary: SORT_STRING

Primer 29a. Primer poravnanja kada su tipovi podataka na

desnoj strani
Int
Int
SORT_STRING
SORT_STRING

SortBoundary;
InsertPos;
InsertVal;
LowerBoundary;

Primer 29b. Primer poravnanja kada su tipovi podataka na

levoj strani

23

b) u jednoj liniji piite samo jednu deklaraciju: Ako se

pridravate ovog saveta imate mogunost da u produetku
svake deklaracije napiete kratak komentar, zatim moete
jednostavnije pronai promenljivu i njen tip, a i eventualne
sintaksne greke se lako otklanjaju jer nam kompajler prilikom
prevoenja uvek daje broj linije u kojoj je nastala greka
c) paljivo poreajte deklaracije: U principu najloginije je da
deklaracije grupiete po tipovima podataka, mada se u nekim
sluajevima moete odluiti i za recimo abecedni redosled.

1.7 Formatiranje komentara

Pisanje komentara je izuzetno vano prilikom programiranja.
Dobro iskomentarisan program je neuporedivo laki za pregled,
razumevanje i kasniju modifikaciju nego program bez komentara ili
loe iskomentarisan program. Evo i nekih optih preporuka za pisanje
komentara u programima:
a) ne koristite komentare koji malo ili nita ne objanjavaju:
Vane komentare treba uiniti uoljivim i itljivim kao u
primeru 30:
*********************************************************
*
*
*
KOMENTAR
*
*
*
*********************************************************

Primer 30. Primer uoljivog komentara

b) poravnajte poetak i kraj komentara: Primer 31 nam

ilustruje ovu preporuku:
(* prva linija komentara
...
poslednja linija komentara
*)

Primer 31. Komentar sa poravnatim poetkom i krajem

c) treba komentarisati svaku proceduru, modul tj. znaajniji

deo programa i kratko opisati namenu svake znaajnije
konstrukcije
d) uvucite i poravnajte komentar koji objanjava neki deo
koda: Na ovaj nain e nam logika struktura samog koda biti
jasnija i itljivija.

24

e) odvajajte komentare jednom praznom linijom: Ako je

program dobro iskomentarisan, osoba koja ga pregleda,
najjednostavnije e to uraditi ako samo "preleti" preko
komentara, bez itanja samog koda. S tim u vezi odvajanje
komentara jednom praznom linijom poboljava itljivost koda.
Evo dva primera koja to ilustruju:
( comment one )
CodeStatementOne;
CodeStatementTwo;
( comment two )
CodeStatementThree;
CodeStatementFour;
Primer 32. Primer dva komenara odvojena jednom praznom
linijom
( comment one )
CodeStatementOne;
CodeStatementTwo;
( comment two )
CodeStatementThree;
CodeStatementFour;

Primer 33. Primer dva komentara odvojena sa dve prazne

linije

U primeru 32 dva komentara smo razdvojili jednom praznom

linijom i time poboljali itljivost, dok smo u primeru 33 ove
komentare odvojili sa dve prazne linije i to pre i posle
komentara.
Estetsko je pitanje koji od ova dva naina ete koristiti, ali
kada se opredelite za jedan, budite dosledni u primeni.

1.8 Formatiranje rutina

Pojedinane naredbe, kontrolne strukture, podaci, deklaracije,
komentari su sastavni delovi rutina i savete za njihov izgled u
programima smo do sad ve opisali. Sada emo se pozabaviti nekim
optim napomenama koje su specifine za rutine kao celine:
a) koristite prazne linije da odvojite delove rutina:
Prvenstveno se odnosti na zaglavlje rutina, deklaracija
promenljivih kao i samog tela rutine.
b) koristite standardno uvlaenje za argumente rutina: Ovaj
problem smo ve razmatrali, a da bi poboljali preciznost,

25

itljivost i olakali modifikaciju programa NEEMO pisati

programe kao toje kod dat u primeru 34:
BOOLEAN ReadEmployeeData( int MaxEmployees, EMP_LIST * Employees,
FILE * InputFile, int * EmployeeCount, BOOLEAN * IsInputError)
...
void InsertionSort(Sort_Array Data, int FirstElmt, int LastElmt)

Primer 34. Primer koda u programskom jeziku C bez

korienja uvlaenja za argumente

BOOLEAN ReadEmployeeData( int

EMP_LIST *
FILE *
int *
BOOLEAN *

MaxEmployees,
Employees,
InputFile,
EmployeeCount,
IsInputError)

...
void InsertionSort(Sort_Array
int
int

Primer

35.

Data,
FirstElmt,
LastElmt)

Poboljanje prethodnog
uvlaenja za argumente

koda

korienjem

U primeru 35 uz minimum truda dobijamo kod koji je itljiv i

"obinim smrtnicima", a ne samo kompjuterima.

26

Naravno da postoji jo naina da se ovaj kod dotera, i njih smo

ve razmatrali u prethodnom delu, ali naredni primer je po
miljenju veine najbolji:

BOOLEAN ReadEmployeeData
(
int
MaxEmployees,
EMP_LIST *
Employees
FILE *
InputFile,
int *
EmployeeCount,
BOOLEAN *
IsInputError
)
...
void InsertionSort
(
Sort_Array
int
int
)

Data,
FirstElmt,
LastElmt

Primer 36. Primer vizuelno najboljeg kodiranja prethodnog primera

c) u C-u koristite novi stil deklaracija rutine: Stil zaglavlja

rutine usvojen u ANSI C standardu razlikuje se od originalnog
stila C zaglavlja. Stari stil pisanja koda zahteva navoenje
promenljivih jednom u zaglavlju, a potom ih opet treba
navesti zajedno sa tipom gde su deklarisane. U primeru 37 dat
je izgled starog stila:
void InsertionSort (Data, FirstElmt, LastElemt )
SORT_ARRAY Data,
int
FirstElmt,
int
LastElmt
(
...
)

27

Primer 37. Primer starog stila pisanja deklaracije rutine u C-u

void InsertionSort
(
SORT_ARRAY Data,
int
FirstElmt,
int
LastElmt
)
(
...
)
Primer 38. Primer novog stila pisanja deklaracije u C-u

1.9 Formatiranje fajlova, modula i

programa
U ovom poglavlju su date neke od osnovnih preporuka za
formatiranje fajlova modula i programa.
a) stavite jedan modul u jedan fajl: Svaki fajl bi trebao da
sadri skup rutina koje slue samo jednom cilju, tj. ine jednu
logiku celinu, a fajl je nain da sve povezane rutine smestimo
u jedan modul. Naime, sve rutine u okviru fajla ine modul.
Dakle moduli predstavljaju semantiko logiki koncept, dok je
fajl fiziki koncept sa stanovita operativnog sistema.
b) u okviru fajla jasno odvojite rutine: Odvojite svaku rutinu
jednu od druge sa minimum dve prazne linije. Jednako su
efektne kao i crtice ili zvezdice, lake ih je i otkucati i
odravati. Koristite dve ili tri da proizvedete vizuelnu razliku
izmeu praznih linija koje su deo rutine i onih koje razdvajaju
rutine. U primeru 39 ovaj zahtev se najbolje ilustruje:
Function Max! ( Arg1!, Arg2! )
'find the arithmetic maximum of Arg1 and Arg2
if ( Arg1! > Arg2! ) then
Max! = Arg1!
else
Max! = Arg2!
endif
end Function
Function Min! ( Arg1!, Arg2! )
'find the arithmetic minimum of Arg1 and Arg2
if ( Arg1! < Arg2! ) then
Min! = Arg1!
else
Min! = Arg2!
28
endif
end Function

Primer 39. Primer odvajanja rutina praznim linijama

Oigledno je da smo koristili jednu praznu liniju da odvojimo

zaglavlje rutine od njenog tela, a dve prazne linije da odvojimo
ove dve rutine.
c) Ako imate vie od jednog logikog modula u fajlu, jasno
identifikujte svaki modul: Rutine koje su povezane trebale bi
da budu zajedno grupisane u modul. Jasno identifikujte svaki
modul koristei nekoliko praznih linija meu njima. Izbegnite
prenaglaavanje komentara unutar modula. Ako morate da
odvojite delove programa dugakim linijama specijalnih
znakova, napravite hijerarhiju tako da zvezdica slui za
deljenje modula, crtice za deljenje rutina, a prazne linije za
odvajanje vanih komentara. Ovo je primenljivo ako vam jezik
ograniava broj fajlova koje moete koristiti u programu. Ako
koristite C ili verziju Pascala, Fortran, Basic koji podravaju
viestruke izvorne fajlove, stavite samo jedan modul u svaki
fajl. Ipak, unutar jednog modula, jo uvek moete imati
podgrupe rutina i moete ih grupisati koristei ovu prikazanu
tehniku. Alternativa je da poreate rutine po azbunom redu,
to moe utedeti vreme pretrage.

29

Function ConvertBlanks$( MixedString$ )

'create string identical to MixedString$ except that the
'blanks are replaced with underscores
dim i%
dim StringLength%
dim WorkString$
WorkString$ = ""
StringLength% = Len( MixedString$ )
for i% = 1 to StringLength%
if (mid$( MixedString$, i%, 1) = " " ) then
WorkString$ = WorkString$ + "_"
else
WorkString$ = WorkString$ + mid$( MixedString$, i%, 1)
endif
next i%
ConvertBlanks$ = WorkString$
end Function
'-------------------------------------------------------------------------------------' MATHEMATICAL FUNCTION
'
' This module contains the program's mathematical function.
'-------------------------------------------------------------------------------------Function Max! ( Arg1!, Arg2! )
'find the arithmetic maximum of Arg1 and Arg2
if ( Arg1! > Arg2! ) then
Max! = Arg1!
else
Max! = Arg2!
endif
end Function
Function Min! ( Arg1!, Arg2! )
'find the arithmetic minimum of Arg1 and Arg2
if ( Arg1! < Arg2! ) then
Min! = Arg1!
else
Min! = Arg2!
endif
end Function
Primer 40. Primer estetskog razdvajanja modula praznim linijama

30

Prva funkcija koju imamo u ovom primeru je zapravo

poslednja rutina prethodnog modula. Poetak novog modula
markirali smo sa nekoliko praznih linija, imenom modula i
estetike radi, sa crticama. Rutine u ovom drugom modulu su
opet meudobno razdvojene po pravilima koja smo ranije
ustanovili. U primeru 41 je predstavljeno poboljanje
prethodnog koda:

'***********************************************************
' MATHEMATICAL FUNCTION
'
' This module contains the program's mathematical function.
'***********************************************************
'---------------------------------------------------------------------------------------Function Max! ( Arg1!, Arg2! )
'---------------------------------------------------------------------------------------'find the arithmetic maximum of Arg1 and Arg2
if ( Arg1! > Arg2! ) then
Max! = Arg1!
else
Max! = Arg2!
endif
end Function
'--------------------------------------------------------------------------------------Function Min! ( Arg1!, Arg2! )
'--------------------------------------------------------------------------------------'find the arithmetic minimum of Arg1 and Arg2
if ( Arg1! < Arg2! ) then
Min! = Arg1!
else
Min! = Arg2!
endif
end Function

Primer 41. Primer poboljanja koda iz prethodnog primera

Zaglavlja obe rutine su odvojena crticama, za razliku od

zaglavlja modula koje je naglaeno zvezdicama, tako da
vizuelno jasno uoavamo da obe rutine pripadaju jednom te
istom modulu.

31

d) u C-u vodite rauna o redosledu u izvornom fajlu

Standardni redosled sadraja izvornog fajla u C-u je:

komentar opisa fajla

definicije konstanti

definicije makroa

definicije tipova

globalne promenljive i uvezene funkcije

globalne promenljive i izvezene funkcije

promenljive i funkcije koje su privatne za sam fajl

REZIME

Prioritet vizuelnog formatiranja je naglaavanje logike

organizacije koda. Kriterijum ukljuuje preciznost, doslednost,
itljivost.

Estetski deo je manje bitan

Dva stila formatiranja u Pascal-u, C, Basic-u su meavina

istih blokova i upotreba bloka begin-end. Formatiranje istim
blokovima moete koristiti ako je program napisan u ADA-i.

Struktuiranje koda je samo po sebi vano. Konvencija formata

koja se nedosledno prati moe koditi itljivosti

32

2. SAMODOKUMENTUJUI KOD
Pored formatiranja samog koda, dobra dokumentacija koda je
stvar programerskog iskustva i etike. Dokumentacija softvera moe da
postoji u mnogo razliitih formi, ali emo se u ovom poglavlju baviti
uglavnom samo komentarima u samom programu.

2.1. Spoljna dokumenta

Dokumentacija o softverskom projektu sastoji se od
informacija izvan i unutar listinga izvornog koda - obino u formi
razdvojenih dokumenata. Na velikim, formalnim projektima veina
dokumentacije je izvan izvornog koda. 2/3 svih napora na velikim
projektima odlazi na kreiranje dokumentacije. Dokumentacija spoljne
konstrukcije tei visokom nivou u poreenju sa kodom, a niskom
nivou u poreenju sa dokumentacijom iz faze pre konstrukcije.
a) Folderi za razvoj jedinica (UDF - Unit development
folders): UDF je neformalni dokument koji sadri beleke
koriene od strane programera tokom konstrukcije. "Jedinica"
je labavo definisana i obino znai ili rutina ili modul.
Osnovna svrha UDF-a je da obezbedi trag dizajnerskih odluka
koje nisu negde drugde dokumentovane. Mnogi projekti imaju
standardni minimum sadraja UDF-a (kopije relevantnih
potreba, delove vrhunskog dizajna koje jedinica koristi, kopija
razvojnih standarda, tekui listing koda) zavisno od zahteva
klijenta.
b) Detaljno dizajniran dokument: To je dokument dizajna
niskog nivoa koji opisuje dizajnerske odluke na nivou modula
ili rutine, alternative koje su uzimane u obzir i razloge za izbor
odabranog pristupa. Ponekad je ova informacija sadrana u
formalnom dokumentu, i u tom sluaju se detaljni dizajn
smatra odvojenim od konstrukcije. Ponekad se sastoji od
programerovih beleaka sakupljenih u UDF, a esto egzistiraju
iskljuivo u samom kodu.

2.2. Programerski stil kao dokumentacija

Nasuprot spoljnoj dokumentaciji, interna dokumentacija se
nalazi u samom listingu programa. Poto je najblie povezana sa
kodom, interna dokumentacije e najverovatnije ostati tana i pri
modifikovanju koda. Dobar programerski stil najvie doprinosi
dokumentaciji na nivou koda. Stil ukljuuje dobru programsku
strukturu, korienje direktnih i lako razumljivih pristupa, dobra
imena promenljivih, dobra imena rutina, korienje imenovanih
konstanti, jasna postavka i minimiziranje sloenosti kontrole protoka i
strukture podataka.

33

2.3. Komentarisati ili ne?

Dobre komentare je tee napisati nego loe, a neprimereno
komentarisanje moe naneti vie tete kodu nego koristi. Ne treba
koristiti komentare koji malo ili nita ne objanjavaju jer samo
optereuju izvorni kod. Svaku rutinu, modul ili znaajniji deo
programa treba kratko opisati kao i namenu svake znaajnije
konstrukcije.

2.4. Kljuevi za efektivne komentare

U ovom poglavlju su date neke od osnovnih preporuka za
kvalitetno pisanje komentara.Vrste komentara se mogu klasifikovati u
pet kategorija:
a) Ponavljanje koda: Ponovljeni komentari pojanjavaju ono
ta kod radi u razliitim situacijama. Oni samo daju onom
koji ita kod vie za itanje bez dodatne pomoi u
razumevanju koda.
b) Objanjenje koda: Komentari koji objanjavaju tipino se
koriste da objasne komplikovane i osetljive delove koda. U
takvim situacijama su korisni, samo zato to je sam kod
konfuzan. Ako je kod toliko komplikovan da ga je potrebno
objanjavati, uvek je uputnije poboljati kod nego dodavati
komentare. Uinite kod jasnijim, a onda koristite sumirajue
ili komentare namere.
c) Markeri u kodu: Marker-komentar je onaj koji nije bio
namenjen ostavljanju u kodu. Oni su podsetnik programeru
da posao nije zavren. Neki programeri ukucaju marker koji
je sintaksno netaan (******, na primer) tako da ih
kompajler obeleava i podsea programera, dok drugi
stavljaju specifian set znakova u komentare tako da mogu
lake da ih pretrauju.
d) Sumiranje koda: Komentari koji sumiraju kod preiste
nekoliko linija koda u jednu ili dve reenice. Naroito su
korisni kad neko ko nije autor originalnog koda pokua da ga
modifikuje.
e) Opis namere koda: Komentari namere objanjavaju svrhu
jednog dela koda i vie su vezani za nivo problema nego
reenja. Jedine dve vrste komentara koje su prihvatljive
kompletnom kodu su sumirajui i komentari namere.

2.4.1 Efikasno komentarisanje

Komentari mogu oduzimati previe vremena da se napiu iz
dva uobiajena razloga:
a) Stil komentara koji zahteva dosta vremena je glavobolja za
odravanje. Ako su komentari teki za menjanje nee biti
promenjeni i postaju netani i vode u zabludu, to je gore
nego uopte nemati komentare.
b) Komentarisanje moe biti teko, jer nije lako nai rei koje
opisuju ta program radi, to je obino znak da ne razumete
ta program radi.
34

c) Vreme koje provedete komentariui je, u stvari, vreme

potroeno na bolje razumevanje programa.

2.4.2. O stilovima komentarisanja

Koristite stilove koji ne obeshrabruju modifikaciju. U primeru
42 navedena su dva sluaja upotrebe komentara koji koriste kitnjasto
oiviene blokove koji su preteki za odravanje:
C
C
C
C
C
C
C
C

Variable
Meaning
------------------XPOS..............X Coordinate Position (in meters)
YPOS..............Y Coordinate Position (in meters)
NDSCMP........Needs Computing (= 0 if no computation is needed,
= 1 if computation is needed)
PTGTTL..........Point Grand Total
PTVLMX.........Point Value Maximum
PSCRMX..........Possible Score Maximum

/*************************************************************
* module: GIGATRON.C
*
*
*
* author: Dwight K. Coder
*
* date:
July 4, 2014
*
*
*
* Routines to control the twenty-first century's code evaluation
*
* tool. The entry point to these routines is the EvaluateCode()
*
* routine at the bottom of this file.
*
*
*
*************************************************************/

Primer 42. Primer komentara koji se teko odravaju

Ako ve morate, zbog naglaavanja, da podvlaite blokove

koristite linije (zvezdice, pluseve, crtice) koje su standardne duine
bez obzira na duinu komentara, jer takve linije ne zahtevaju
odravanje i moete im lako prii tekst-editorom. U primeru 43 je
ilustrovan ovaj princip:

35

/********************************************************
module: GIGATRON.C
author: Dwight K. Coder
date:
July 4, 2014
Routines to control the twenty-first century's code evaluation
tool. The entry point to these routines is the EvaluateCode()
routine at the bottom of this file.
********************************************************/

Primer 43. Naglaavanje komentara linijama iste duine

2.4.3. Optimalan broj komentara

Projekti ponekad usvajaju standard kao to je "program mora
imati najmanje jedan komentar na svakih pet linija", to znai da
programer nije napisao jasan kod. Ako efikasno koristite proces "PDL
(program design language) ka kodu" verovatno ete zavriti sa
komentarom na svakih nekoliko linija koda. Broj komentara e biti
propratni efekat samog procesa.
Fokusirajte se na to da li je svaki komentar efikasan. Ako
komentari opisuju zato je kod napisan i izlaze u susret ostalim
kriterijumima iz ovog poglavlja onda ih imate dovoljno.

2.5. Tehnike komentarisanja

Komentarisanje je podlono razliitim tehnikama u zavisnosti
od nivoa na koji se komentari primenjuju: program, fajl, rutina, skup
ili individualna programska linija.

2.5.1 Komentarisanje individualnih linija

Postoje dva mogua razloga kada je jednoj liniji koda potreban
komentar i to:
a) jedna linija je dovoljno komplikovana da joj treba
objanjenje
b) jedna linija je nekada imala greku i potrebna je beleka o
greci
Izbegavajte samo-udovoljavajue tj. line komentare: ta su
zapravo lini komentari? To e nam najbolje pokazati sledea kratka
pria: Relativno davno, programera koji je bio zaduen za odravanje
softvera u nekoj kompaniji probudili su u pola noi da ispravi greku u
nekom programu, poto je autor originalnog koda nedavno napustio
kompaniju pa nije vie dostupan. Novi programer je doao, pregledao
dokumentaciju, source i u celom kodu pronaao jednu programsku
liniju sa jednim komentarom koja izgleda ovako:

36

Mov AX, 723h

; R. I. P. L. V. B.

Poto mu ovo naravno nita nije znailo, ostatak noi, programer je

proveo traei greku i pred zoru je najzad uspeno zavrio posao.
Posle nekoliko meseci, sreto se sa bivim kolegom na nekoj
konferenciji i upitao je autora programa ta mu zapravo znai onaj
komentar? Odgovor je bio sledei: R. I. P. L. V. B. znai "Rest in
peace, Ludwig van Bethoven"!!! Objanjenje je sledee: Betoven je
umro 1827. godine, a kada broj 1827 iz dekadnog brojnog sistema
prevedete u heksadecimalni dobijate naravno 723h! Oigledno je da su
ovakvi komentari besmisleni i treba ih izbegavati.

2.5.2 Endline komentari i problemi sa njima

To su komentari koji se pojavljuju neposredno posle linije
koda, kao to im i ime kae. Iako su u nekim okolnostima korisni,
uzrokuju i razne probleme. Komentari moraju biti povezani na desnoj
strani koda, tako da se ne meaju u vizuelnu strukturu koda. Endline
komentari se u principu teko formatiraju. Takoe ih je teko
odravati. Ako na bilo kojoj liniji koja ima endline komentar kod
naraste, izgurae komentar jo vie u stranu i svi ostali komentari e
morati biti pomereni tako da se slau. Tada komentarisanje, umesto da
se poboljava posle modifikovanja, propada.
Ovi komentari takoe tee ifriranosti. Zbog elje da se
komentar zadri na jednoj liniji, radi se na skraenju linije umesto
njenoj jasnoi, i komentar obino zavri maksimalno ifriran tj.
zapisan skraenicama ije ete znaenje najverovatnije ubrzo
zaboraviti. U nastavku je dato nekoliko preporuka za pisanje endline
komentara:
a) Izbegnite endline komentare na pojedinanim linijama:
Osim praktinih, predstavljaju i konceptualne probleme.
Sistemski problem sa njima je taj to je teko napisati smisaoni
komentar za jednu liniju koda.Veina ovih komentara samo
ponavlja liniju koda, to vie kodi nego to pomae.
b) Izbegnite endline komentare za viestruke linije koda: Ako
je namera da se komentar primenjuje na vie od jedne linije
koda formatiranje ne pokazuje na koje se linije odnosi
Evo primera koji to ilustruje:
for RateIdx : = 1 to RateCount do begin ( Compute discounted rates )
begin
LookupRegularRate( RateIdx, RegularRate );
Rate[ RateIdx ] : = RegularRate * Diskount[ RateIdx ]
end;

Primer 44. Primer endline komentara za viestruke linije koda

37

c) Kada se koriste endline komentari

Ovakvi komentari su ponekad jako korisni i u nastavku su
navedeni sluajevi kada se preporuuju
koristite ih da objasnite deklaracije podataka: Za to su
pogodni, jer nemaju iste sistemske probleme kao endline
komentari na kodu, pod pretpostavkom da imate dovoljno
irine.
koristite endline komentare za beleke o odravanju:
Korisni su za beleenje modifikacije koda posle njegovog
poetnog razvoja. Ova vrsta komentara se tipino sastoji od
datuma i inicijala programera ili mogue broja izvetaja o
greci. Takvim komentarima se bolje rukuje u versioncontrol programu, ali ako nemate podrku drugih alata, a
elite da objasnite poziciju pojedinane linije, ovo je nain
na koji to radite.
koristite ih da markirate krajeve blokova: Korisni su za
markiranje kraja dugakog bloka koda (kraj "while" loop-a
ili "if" iskaza, npr.). Osim u par specifinih sluajeva,
endline komentari imaju konceptualne probleme i tee
korienju za previe komplikovane kodove. Teko ih je
formatirati i odravati i najbolje ih je izbegavati.

2.5.3 Komentarisanje paragrafa koda

Veina komentara u dobro dokumentovanom programu u
jednoj ili dve reenice opisuju paragraf koda. Komentari ne ponavljaju
kod ve opisuju namere koda. Takvi komentari su relativno laki za
odravanje. ak i ako naete greku, neete morati da menjate
komentar. Komentari koji nisu napisani da izraze nameru koda tei su
za odravanje. Primer dobrog komentarisanja na nivou paragrafa koda
je dat u primeru 45:
/* swap the roots */
OldRoot = root[0];
root[0]
= root[1];
root[1]
= OldRoot

Primer 45. Primer komentarisanja na nivou paragrafa koda

U nastavku sledi nekoliko preporuka za komentarisanje paragrafa

koda:

38

a) Piite komentare da izraavaju nameru koda: Opiite svrhu

bloka koda koji prati komentar. U primeru 46 je dat komentar
koji nije efikasan, jer samo ponavlja kod i ne daju uvid u to ta
kod radi:
( check each character in "InputStr" until a dollar sign
is found or all characters have been checked )
Done
: = False;
MaxLen : = Length( InputStr );
i
: = 1;
while ( (not Done) and ( i < = MaxLen) )
begin
if ( InputStr[ i ] = '$' ) then
Done : = True;
else
i := i + 1
end;

Primer 46. Primer neefikasnog komentara

Zakljuak je da su najbolji komentari koji sadre informacije

kojih nema u listingu koda, odnosno to to saznate iz
komentara ne biste zakljuili iz itanja fragmenta koda.
Drugi nain razmiljanja o komentarisanju za izraavanje
namere koda je da razmislite o tome kako biste nazvali rutinu
koja radi iste stvari kao i kod koji elite da komentariete.
To nije teko ako piete paragrafe koda gde svaki ima po jednu
svrhu. Kucajte opis bez skraivanja kao to biste uradili za ime
rutine. Taj opis je va komentar i verovatno izraava nameru.
Ako je kod deo neke druge rutine, nainite drugi korak i stavite
kod u sopstvenu rutinu. Ako kod dobro obavlja definisanu
funkciju i dobro imenujete rutinu, pridodaete itljivosti i
odrivosti vaeg koda. Sam kod je prva dokumentacija koju
biste trebali da proverite. To pravi jasnu razliku izmeu
indeksa loop-a i rezultata loop-a. Ako je kod dovoljno dobar,
zadire u komentarsko objanjenje da izrazi nameru koda. U
jednoj taki kod i komentar mogu postati suvini, ali taj
problem ima samo nekolicina programa. U primeru 47 dat je
kod iz prethodnog primera prepravljen po navedenim
uputstvima:

39

( find the command-word terminator )

FoundTheEnd
: = False;
MaxCommandLength : = Length( InputStr );
Idx
: = 1;
while ( (not FoundTheEnd) and ( Idx < = MaxCommandLength) )
begin
if ( InputStr[ Idx ] = COMMAND_WORD_TERMINATOR ) then
begin
FoundTheEnd
: = True;
EndOfCommand : =Idx
end
else
Idx : = Idx + 1
end;

Primer 47. Primer komentara koji izraava nameru koda

b) Fokusirajte komentare paragrafa na " zato" pre nego

"kako" : Komentar koji objanjava kako je neto uraeno
obino operie na nivou jezika programiranja pre nego na
nivou problema. Skoro je nemogue da komentar, koji je
fokusiran na to kako je operacija uraena, objasni nameru
operacije, i komentari koji objanjavaju "kako" su obino
suvini. Naveemo tri primera i opet zakljuiti da je najbolji
komentar koji sadri ono to se iz samog koda ne moe
saznati:
/* if allocation flag is zero */
if (AllocFlag = = 0) ...
Primer 48. Primer komentara koji je suvian

Prethodni komentar se fokusira na "kako" i ne govori nam

nita to ne moemo lako proitati iz koda. Poboljana verzija
je data u primeru 49:
/* if allocating new member */
if (AllocFlag = = 0) ...
Primer 49. Poboljana verzija prethodnog primera

Sada kod mnogo bolje izgleda jer ovu informaciju iz

komentara nemamo u samom kodu. Jo je bolje ako uvedemo
40

neku smislenu konstantu umesto 0, pa najzad dobijamo

najbolju verziju ovog segmenta koda i komentara:
/* if allocating new member */
if (AllocFlag = = NEW_MEMBER) ...

Primer 50. Primer efikasnog komentarisanja

c) Koristite komentare da pripremite itaoca za ono to sledi:

Dobri komentari govore osobi koja ita kod ta da oekuje.
italac bi trebao biti u stanju da skenira samo komentare i iz
toga sazna ta kod radi i gde da trai posebne aktivnosti.
Posledica ovog pravila je da bi komentar uvek trebao biti
ispred koda koji opisuje.
d) Neka se svaki komentar rauna: Preterano komentarisanje
nije vrlina. Komentari slue da razjasne kod i umesto pisanja
vie komentara, uloite ekstra napor da sam kod bude itljiviji.
e) Dokumentujte iznenaenja: Ako imate bilo ta to nije
oigledno iz samog koda, obavezno to komentariite. Ako ste,
da biste poboljali performanse, koristili neko programersko
lukavstvo ili trik, koristite komentare da istaknete kako bi
drugaiji pristup uticao na performanse.
U navedenom primeru desni shift je namerno korien. Meu
iskusnim programerima uobiajeno znanje je da je za Integer-e
(cele brojeve) desni shift funkcionalni ekvivalent za "deliti sa
dva". Znaajna je injenica da kod ne koristi tehniku koja
najvie odgovara svrsi. ta vie, veina kompajlera
optimalizuje kod tako da desni shift slui za deljenje celih
brojeva sa dva, to znai da je smanjena jasnoa obino
nepotrebna. Sa dokumentacijom, programer koji ita kod e
videti motivaciju za korienje manje oigledne tehnike. Bez
komentara isti programer e stei utisak da je kod nepotrebno
"pametan" bez pravog dobitka u performansi. Zato je bitno
dokumentovati izuzetke.
for ( i = 0; i < ElmtCount; i++ )
(
/* Use right shift to divide by two. Substituting the
right-shift operation cuts the loop time by 75% */
Elmt[ i ] = Elmt[ i ] >>1;
)
Primer 51. Primer komentarisanja iznenaenja u kodu

41

f) Izbegnite skraenice: Komentari bi trebali biti nedvosmisleni,

bez potrebe da se shvataju skraenice. Zato u komentarima
izbegavajte sve osim najuobiajenih skraenica.
g) Napravite razliku izmeu velikih i malih komentara: U
nekim sluajevima trebae vam da napravite razliku u nivoima
komentara, pokazujui da je komentar detalja deo prethodnog,
optijeg komentara. Ovo se moe uraditi na nekoliko naina.
Moete podvui veliki komentar, a ne podvui manji. Mana
ovog pristupa je da vas tera da podvuete vie komentara nego
to biste eleli. Ako podvuete komentar, pretpostavka je da je
svaki sledei koji nije podvuen njemu podreen. I naravno,
kad napiete prvi komentar koji nije podreen podvuenom,
morate i njega podvui i krug se nastavlja. Rezultat je previe
podvlaenja ili nedosledno podvlaenje na nekim mestima i ne
podvlaenje na drugim. Ova tema ima nekoliko varijacija i sve
imaju isti problem. Ako svim veim komentarima oznaite
gornji deo, a manjim donji, zamenjujete problem previe
komentara oznaenih pri vrhu sa problemom previe
podvuenih komentara.
Bolji pristup je korienje tri take (...) ispred manjeg
komentara. esto najbolji pristup je stavljanje operacije
glavnog komentara u sopstvenu rutinu. Rutine bi trebale biti
logiki "ravne" sa svim svojim aktivnostima u otprilike istom
logikom nivou. Ako va kod pravi razlike veih i manjih
aktivnosti u okviru rutine, rutina onda nije ravna. Stavljanje
komplikovane grupe aktivnosti u sopstvenu rutinu ini da
imate dve logiki ravne umesto jedne logiki klimave rutine.
Ova diskusija o veim i manjim komentarima se ne odnosi na
uvuene kodove unutar loop-ova i uslova. U takvim
sluajevima, esto ete imati irok komentar na vrhu loop-a i
komentare sa vie detalja o operacijama unutar uvuenog koda.
U tim sluajevima uvuenost obezbeuje uvid u logiku
organizaciju komentara. Ova diskusija se odnosi samo na
sekvencijalne paragrafe koda u kojima nekoliko paragrafa ini
kompletnu operaciju i neki paragrafi su podreeni drugima.
h) Opravdajte naruavanje dobrog stila programiranja: Ako
ste morali to da uradite, objasnite zato. To e spreiti
dobronamernog programera da promeni kod u bolji stil,
verovatno sruivi va kod. Objanjenje e staviti do znanja da
sta znali ta radite i da niste samo bili aljkavi i neupueni.
i) Ne komentariite "teak" kod: Preovlaujue je miljenje da
bi komentari naroito trebali da slue za dokumentovanje
tekih i osetljivih delova koda. Rezon je taj da bi ljudi trebalo
da znaju da budu paljivi kad rade u odreenim podrujima.
Ovo je prilino pogrean stav. Komentari ne mogu spasiti
teak kod. Ako se vama ini tekim, drugima e biti
nerazumljivo. Uvek moete nai prepis koji nije teak, pa
prepiite kod. Uinite va kod tako dobrim da vam ne trebaju
komentari, a onda ga komentariite da bude jo bolji. Ovaj

42

savet je primenljiv za kod koji piete prvi put. Ako odravate

program i nemate irinu da prepravite lo kod, komentarisanje
loih delova je dobra veba.

2.5.4 Komentarisanje deklaracija podataka

Komentari deklaracija promenljive opisuju aspekte
promenljive koje ime promenljive ne moe opisati. Veoma je vano
paljivo dokumentovati podatke. Unastavku je dato nekoliko
praktinih saveta za komentarisanje deklaracija podataka:
a) Komentariite jedinice numerikih podataka: Ako broj
predstavlja duinu, komentar treba da sadri objanjenje da li
je duina izraena u inima, stopama, metrima ili kilometrima.
Ako je u pitanju vreme, pokaite da li je izraeno u proloj
sekundi poev od 1-1-1980, da li je u milisekundi poev od
starta programa. Ako su u pitanju koordinate, da li
predstavljaju duinu, irinu i visinu i da li su u radijanima ili
stepenima; da li predstavljaju X, Y, Z koordinatni sistem sa
korenom u zemljinom centru itd. Nemojte pretpostaviti da su
jedinice oigledne. Novom programeru ili nekom ko je radio
na drugom delu sistema nee biti oigledne, pogotovo posle
bitne modifikacije.
b) Komentariite dozvoljene
numerike vrednosti: Ako
promenljiva ima oekivani okvir vrednosti, dokumentujte
oekivani okvir. Ako jezik podrava ogranienje okvira (kao
to ine Pascal i Ada), ograniite okvir. Ako ne, koristite
komentar da dokumentujete oekivani okvir vrednosti.
c) Komentariite kodirana znaenja: Ako va jezik podrava
tipove nabrajanja (kao Pascal, C, Ada), koristite ih da izrazite
kodirano znaenje. Ako ne podrava, koristite komentare da
pokaete ta svaka vrednost predstavlja i koristite imenovane
konstante za svaku vrednost.
d) Komentariite ogranienja na ulaznim podacima: Ulazni
podaci mogu dolaziti od ulaznog parametra, fajla ili ulaza
direktnog korisnika. Gore navedene vodilje su primenljive
kako na parametre ulaza rutine tako i na druge vrste podataka.
Uverite se da su oekivane i neoekivane vrednosti
dokumentovane. Komentari su nain dokumentovanja da
rutina nikad ne bi trebala da primi siguran podatak. Kontrola
ulaza je drugi nain i ako znate da je koristite kod za toliko
vie postaje samo-proveravajui.
U nastavku je dat primer koji ilustruje ove etiri preporuke:

43

var
CursorX:
CursorY

1..MaxCols; ( horizontal screen position of cursor )

1..MaxRows; ( vertical position of cursor on screen )

AnennaLength: Real;
SignalStrength: Integer;
CharCode: 0..255;
CharAttrib: Integer;
CharSize: 4..127

( length of antenna in meters; > = 2 )

( strength of signal in kilowats; > = 1 )
( ASCII caracter code )
( 0 = Plain; 1 = Italic; 2 = Bold; 3 = BoldItalic )
( size of character in points )

Primer 52. Primer pravilnog komentarisanja deklaracije

podataka

e) Dokumentujte FLAG-ove do nivoa BIT-a: Ako je

promenljiva koriena kao polje BIT-a, dokumentujte znaenje
svakog BIT-a posebno. U nastavku je dat jedan primer:
var
{ The meanings of the bits in StatusFlags are as follows:
MSB

LSB

0
1-2
3
4
...
14
15

error detected: 1 = yes, 0 = no

kind of error: 0 = syntax, 1 = warning, 2 = severe, 3 = fatal
reserved ( should be 0 )
printer status: 1 = ready, 0 = not ready
not used ( should be 0)
not used ( should be 0) }

StatusFlags: integer;

Primer 53. Primer komentarisanja Flag-ova na nivou bita

f) Poveite komentare vezane za promenljive sa imenima

promenljivih: Ako imate komentare koji se odnose na
odreenu promenljivu, uverite se da e komentar biti auriran
svaki put kad i promenljiva. Jedan nain da poboljate anse za
doslednu modifikaciju je da poveete komentar sa imenom
promenljive. Na taj nain, pretraga niza za imenom
promenljive e dovesti kako do promenljive tako i do
komentara.
g) Dokumentujte globalne podatke: Ako je korien globalni
podatak, dobro objasnite svaki deo u taki u kojoj je
deklarisan. Objanjenje bi trebalo da pokae svrhu podatka i
zato je potrebno da bude globalan. Na svakom mestu gde je
podatak korien, jasno stavite da je podatak globalan.
44

2.5.5 Komentarisanje kontrolnih struktura

Prostor pre kontrolne strukture obino je prirodno mesto gde
da stavite komentar. Ako je u pitanju "if" ili "case" iskaz, dobijate
razlog odluke i sumiranje ishoda. Ako je "loop" u pitanju, moete
naznaiti svrhu loop-a. U primeru 54 sledi ilustracija ove preporuke:
/* copy input field up to comma */
while ( *InputStr != ',' && *InputStr != END_OF_STRING )
{ *Field = *InputStr;
Field++
InputStr++;
} /* while... copy input field */
*Field = END_OF_STRING;
/* if at end of string, all actions are complete */
if ( *InputStr != END_OF_STRING )
{
/* read past comma and subsequent blanks to get to the
next input field */
InputStr++;
while ( *InputStr = = ' ' && *InputStr != END_OF_STRING
InputStr++
} /* if ... at end of string */

Primer 54. Primer komentarisanja kontrolnih struktura

U nastavku su date jo neke opte preporuke koje su se u praksi

pokazale kao korisne prilikom komentarisanja kontrolnih struktura:
a) Stavite komentar pre svakog bloka iskaza, if, case, loop:
Ovakve konstrukcije esto zahtevaju objanjenje i koristite
komentar da pojasnite kontrolne strukture.
b) Komentariite kraj svake kontrolne strukture: Koristite
komentar da prikaete da je deo posla zavren. Komentar je
naroito od pomoi kod duih ili grupisanih petlji. U jezicima
koji podravaju imenovane petlje (Ada), imenujte ih. U drugim
jezicima koristite komentare da pojasnite grupisanje petlji. U
nastavku emo navesti jedan primer (primer 55) u Pascalu gde
se koriste komentari za pojanjenje krajeva petlji struktura.
Ova tehnika komentarisanja dopunjuje vizualne znake o
logikoj strukturi koji su dati uvlaenjem koda. Ova tehnika se
isplati kada su petlje dugake ili duboko ugnjedene.

45

for TableIdx : = 1 to TableCount

begin
while (RecordIdx < RecordCount )
begin
if ( not IllegalRecNum( RecordIdx )
)
begin
...
end; { if }
end; { while }
end; { for }
Primer 55. Primer komentarisanja kraja kontrolnih struktura

2.5.6 Komentarisanje rutina

Komentari na nivou rutine podloni su najgorim savetima u
tipinim knjigama o kompjuterskim naukama. Mnoge knjige teraju
nas da gomilamo informacije na vrhu svake rutine, bez obzira na
njihovu veliinu ili sloenost. To je siguran recept za neprecizne
komentare i promaaje u odravanju (puno posla koji se nikada ne
isplati). U primeru 56 prikazano je kako ne treba raditi:

46

'*********************************************************
'
' Name: CopyString
' Purpose:

This routine copies a string from the source

string (Source$) to the target string (Target$)

'
' Algorithm: It gets the length of Source$ and then copies each
'
character, one at a time, into Target$. It uses
'
the loop index as an array index into both Source$
'
and Target$ and increment the loop/array index
'
after each character is copied.
'
' Input:
Input$
The string to be copied
'
' Outputs:
Output$
The string to receive the copy of Input$
'
' Interface Assumptions:
None
'
' Modification History:
None
'
' Author:
Dwight K. Coder
' Date Created:
10/01/92
' Phone:
(222) 555 - 2255
' SSN:
111 - 22 - 3333
' Eye Color:
Green
' Maiden Name:
None
' Blood Type:
AB' Mothers Maiden Name: None
'
'*********************************************************

Primer 56. Primer neadekvatnog komentarisanja rutine

Gore navedena rutina je trivijalna i ima samo nekoliko linija

koda, a pogledajte samo koliko ima komentara!
Da bi izbegli ovakav nain komentarisanja, u nastavku emo
dati nekoliko ideja vodilja za komentarisanje rutina:
a) Drite komentare blizu koda koji opisuju: Jedan razlog
zato prolog rutine ne treba da sadri obimnu dokumentaciju je
da takva praksa stavlja komentare daleko od dela rutine koji
opisuju. Tokom odravanja, komentari koji su daleko od koda
esto ostaju nepromenjeni ako se kod menja. Komentari i kod
poinju da se ne slau i odjednom komentari postaju
bezvredni. Umesto toga, sledite "princip priblinosti", i
stavljajte komentare to je mogue blie kodu koji opisuju.
Vea je verovatnoa da e biti odravani i ostae vredni truda.

47

b) Opiite svaku rutinu sa jednom ili dve reenice pri vrhu

iste: Ako moete to da uradite, morate dublje da razmislite ta
bi ta rutina trebalo da radi. Tekoe u kreiranju kratkih opisa
su znak da dizajn i nije dobar kao to bi trebao biti i onda ga
treba poboljati. Kratki, sumirajui iskazi trebali bi biti prisutni
u skoro svim rutinama.
c) Dokumentujte ulazne i izlazne promenljive tamo gde su
deklarisane: Ako ne koristite globalne podatke, najlaki nain
dokumentovanja ulaznih i izlaznih promenljivih je da stavite
komentare pored deklaracija parametara. Ova praksa je dobar
izuzetak od pravila ne korienja endline komentara, jer su
izuzetno korisni u dokumentovanju ovih promenljivih. Primer
57 je dobra ilustracija vrednosti korienja standardne
uvuenosti umesto endline uvuenosti za parametarsku listu
rutine. Taj primer takoe pokazuje da komentari nisu jedina
dokumentaciona forma. Ako su imena promenljivih dovoljno
dobra, moi ete da preskoite komentarisanje istih. Najzad,
potreba za dokumentovanjem ulaznih i izlaznih promenljivih je
dobar razlog za izbegavanje globalnih podataka.
procedure InsertionSort
(
Var Data:
tSortArray; { sort array elements FirstElmt..LastElmt }
FirstElmt:
Integer;
{ index of first element to sort }
LastElmt
Integer;
{ index of last element to sort }
);

Primer 57. Primer dobrog imenovanja promenljivih

d) Pravite razliku izmeu ulaznih i izlaznih podataka: Korisno

je znati koji podatak je korien kao ulaz, a koji kao izlaz. U
Pascal-u je to lako razaznati, jer u njemu izlaznom podatku
prethodi slubena re "var" dok ulaznom podatku ne prethodi.
Ako jezik ne podrava takvo automatsko razlikovanje
napravite to u komentarima (dati primer 58 je u C-u). Bie
bolje ako ulazne i izlazne argumente eksplicitno identifikujete.
Ako su rutine dovoljno kratke i odravate jasno razlikovanje
izmeu ulaznih i izlaznih podataka, ovaj proces je nepotreban.
void StringCopy
(
char * Target
char * Source
)

/* out: string to copy to */

/* in: string to copy from */

Primer 58. Primer korienja komentara za razlikovanje ulaznih i

izlaznih podataka

48

e) Beleite istorijat promene rutine: Pratite promene uraene

na rutini posle poetne konstrukcije. Promene se esto rade
zbog greaka, a mnogo greaka u rutini znai da ista rutina
verovatno ima jo vie greaka. Praenjem otkrivenih greaka
u rutini, kada broj greaka dostigne odreenu taku, znaete da
je vreme da redizajnirate i ponovo napiete rutinu. Ovo se ne
oekuje od vas da radite za svaku rutinu, jer ne oekujete u
svakoj rutini greke. Ako vam previe greaka zagui vrh
rutine, prirodno je da se otarasite smetnji i napiete rutinu
ponovo. Veina programera uiva kad ima razlog da prepravi
kod za koji su i tako znali da je mogao biti bolje napisan, i ova
dokumentacija je dobar, vidljiv razlog za tako neto.
f) Komentariite limite rutine: Ako rutina obezbeuje
numeriki rezultat, nagovestite preciznost rezultata. Ako su
prorauni pod nekim uslovima nedefinisani, dokumentujte
uslove. Ako se rutina nepravilno ponaa kad dospe u nevolju,
dokumentujte ponaanje.
g) Dokumentujte izvor korienih algoritama: Ako ste koristili
algoritam iz knjige ili asopisa, dokumentujte obim i broj
strane sa koje ste ga uzeli. Ako ste algoritam sami razvili,
nagovestite itaocu gde da nae beleke koje ste nainili o
tome.
h) Koristite komentare da obeleite delove programa: Neki
programeri to rade da mogu lake da ih nau. Jedna od tehnika
u C-u je da obelee vrh svake rutine komentarom (/*** npr.).
To vam dozvoljava da skaete sa jedne na drugu rutinu
pretragom niza znakova /***. Slina tehnika je da razliite
vrste komentara razliito obeleite. Na primer, u Pascalu
moete koristiti {-X-, gde je x ifra koju koristite da
nagovestite vrstu komentara. Komentar {- R- moe
nagovetavati da komentar opisuje rutinu, {-L- lokalne
deklaracije itd. Ova tehnika doputa korianje raznih alata za
izvlaenje razliitih vrsta informacija iz izvornog fajla. Na
primer, uradite pretragu za {-R- dobiete opise svih rutina.

2.5.7 Komentarisanje fajlova, modula i

programa
Fajlove, module i programe karakterie injenica da svi sadre
viestruke rutine. Fajl ili modul bi trebali da sadre kolekciju
meusobno povezanih rutina. Program sadri sve rutine u programu.
Zadatak dokumentovanja je obezbediti smisaoni, vrhunski pregled
sadraja fajla, modula ili programa. Dakle, u nastavku emo dati neke
praktine savete za dokumentovanje fajlova, a ti saveti se naravno
odnose i na module i programe.
a) Opiite svrhu svakog fajla: Ako su rutine za program u
jednom fajlu, svrha fajla je oigledna. Ako radite na programu
sa viestrukim modulima i moduli su razdvojeni u viestruke
fajlove, objasnite zato je odreena rutina stavljena u odreen
49

fajl. Opiite svrhu svakog fajla. Poto je u ovom sluaju jedan

fajl jednak jednom modulu to e biti dovoljna dokumentacija.
Ako je deljenje u viestruke izvorne fajlove raeno iz nekog
drugog razloga osim modularnosti, dobar opis svrhe fajla bie
od jo vee koristi programeru koji modifikuje program.
b) Stavite svoje ime i telefon u blok komentar: Vrlo je vano
imati informaciju o autorstvu u listingu. Drugim programerima
koji rade na kodu daje nagovetaj o programerskom stilu i
koga da nazovu ako im zatreba pomo. U zavisnosti da li
radite na individualnim rutinama, modulima ili programima, na
tom nivou stavite informaciju o autoru.
c) Ukljuite "copyright" izjavu u komentar: Nije zgoreg u
programu imati tekst slian ovom iz primera 59, naravno sa
vaim podacima, koji se odnosi na autorska prava i copyright.
/* (c) Copyright 1993 Steve McConnell, Inc. All Rights Reserved
Primer 59. Primer komentara koji se odnosi na autorska prava

REZIME
Ako se komentarisanje uradi siromano, to je protraeno
vreme, a ponekad moe i da kodi. Isplativo je ako je komentarisanje
dobro uraeno. Listing izvornog koda bi trebao da sadri veinu
kritinih informacija o programu. Listing je jedini dokument koji se
garantovano nee zagubiti dok je program u toku, a i korisno je imati
vane informacije zajedno sa kodom. Dobri komentari su napisani da
izraze nameru. Oni ne objanjavaju ZATO nego KAKO. Komentari
treba o kodu da kau one stvari koje sam kod ne moe. Dobar kod je
sam sebi najbolja dokumentacija. Pre nego to dodate komentar kodu,
zapitajte se kako moete da poboljate kod da vam taj komentar bude
nepotreban. Poboljajte kod, a onda ga dokumentujte da ga uinite jo
jasnijim.

50

3. PROGRAMSKI ALATI
Moderni programerski alati smanjuju koliinu vremena
potrebnu za konstruisanje softverskih proizvoda. Korienje vrhunskih
alata moe poveati produktivnost rada i preko 50 procenata.
Programerski alati takoe mogu smanjiti koliinu smarajueg posla
oko detalja koje programiranje zahteva. Cilj ovog poglavlja je da opie
alate koje moete napraviti ili kupiti za pomo pri konstruisanju
softverskog proizvoda. Ovo poglavlje je koncentrisano u dva pravca.
Prvi je da pokriva iskljuivo konstrukcijske alate, a drugi je da ovo
poglavlje pokriva vrste alata, a ne odreene marke iz prostog razloga
to se verzije, proizvodi pa i same kompanije koje ih proizvode veoma
brzo menjaju da nema smisla diskutovati o tome jer dok ovo itate
verovatno se pojavio ve neki novi alat, nova verzija starog ili novi
proizvoa tako da vam je vanije da znate koja vrsta alata vam treba.

3.1 Alati dizajna

Alati dizajna koji su trenutno u opticaju uglavnom su grafiki
alati koji kreiraju dijagrame dizajna. Ponekad su alati dizajna
uklopljeni u CASE alat sa irim funkcijama, a neki snabdevai
samostalne alate predstavljaju kao CASE. Grafiki alati dizajna
obino vam dozvoljavaju da izrazite dizajn u uobiajenim grafikim
belekama (hijerarhijske mape, HIPO (Hierarchy Input Process
Output) dijagrami, dijagrami povezanosti entiteta, strukturne mape,
dijagrami modula). Neki alati grafikog dizajna podravaju samo
jednu notaciju, drugi podravaju mnotvo, a veina ih podrava PDL
(program design language). Dizajnerski alati vam daju mogunost
kretanja izmeu viih i niih nivoa apstrakcije, a neki od njih mogu da
kreiraju kod direktno iz vaeg dizajna.

3.2. Alati izvornog koda

Ova grupa alata je povezana sa editovanjem izvornog koda.
a) Editori: Neki programeri procenjuju da troe i do 40%
vremena editujui izvorni kod. U tom sluaju potroiti jo
malo novca na najbolje mogue editore je dobra investicija. Uz
dodatak osnovnim funkcijama za formatiranje teksta dobri
editori za programiranje nude: kompilaciju greke unutar
editora, kompresovani pregled programa (samo imena rutina ili
logike strukture sadraja), interaktivnu pomo u editovanju
jezika, begin-end poklapanje, ablone za uobiajene jezike
konstrukcije, pametno uvlaenje (ukljuujui laku promenu
uvlaenja bloka iskaza kada se logika promeni), MACRO-i
koji su u stanju da budu programirani u uobiajenim
programskim jezicima, memoriju nizova pretrage, regularne
izraze u "pretrai i zameni" opciji, pretrai zameni opciju

51

preko grupe fajlova, istovremeno editovanje viestrukih

fajlova, otvaranje na vie nivoa.
Sa obzirom da veina ljudi koristi primitivne editore,
iznenadiete se kad ujete da neki poseduju sve ove
sposobnosti.
b) Alati koji menjaju stringove u viestrukim fajlovima: esto
je korisna mogunost da menjate stringove preko viestrukih
fajlova. Na primer, mogue je konstantu ili globalnu
promenljivu zameniti boljim imenom. Osim toga, moda ete
morati da promenite ime u nekoliko fajlova. Pogodnosti koje
dozvoljavaju promene stringa kroz viestruke fajlove
olakavaju tu aktivnost. Jedan od dostupnijih alata koji prua
pretrai-zameni opciju u viestrukim fajlovima je AWK
programski jezik. Glavna vrlina AWK-a je je dobro rukovanje
nizovima i grupama fajlova, pa je i dobar za menjanje nizova
kroz grupe fajlova.
c) Komparatori fajla: Programeri esto imaju potrebu da
uporede dva fajla. Ako napravimo nekoliko pokuaja da
uklonimo neku greku u fajlu i moramo da uklonite neuspele
pokuaje, komparator fajla e uporediti originalni i
modifikovani fajl i izlistati linije u kojima je bilo promena.
Ako radimo na timskom projektu i elimo da vidimo promene
koje su ostali lanovi tima uradili, imamo mogunost da
poreamo tekue i verzije na kojoj smo radili. Kao rezultat
dobijamo izmene koje su napravili ostali lanovi tima. Ako
naiemo na defekt, a ne seamo se da li smo se sretali sa njim
ranije, koristimo komparator za poreenje prole i sadanje
verzije, i na taj nain moemo otkriti ta se tano promenilo i
nai izvor problema.
d) Alati koji ulepavaju izvorni kod: Ovi alati doteruju izvorni
kod tako da izgleda bolje formatiran. Oni standardizuju stil
uvlaenja, povezuju deklaracije promenljivih i veznike rutina,
formatiraju komentare dosledno i obavljaju druge sline
funkcije. Tokom tampanja, neki "ulepivai" poinju svaku
rutinu na vrhu nove strane ili obavljaju jo dramatinije
formatiranje. Osim to ine da kod izgleda lepo, mogu
obavljati i niz drugih funkcija. Ako je pojedine delove koda
radilo nekoliko programera u nekoliko razliitih stilova,
"ulepivai" koda mogu promeniti kodove u unificiranu formu.
e) Uzorci (template): Pomau pri formatiranju koda koje radimo
esto i elimo da radimo dosledno. Pretpostavimo da elite
standardni komentarski uvod na poetku vaih rutina. Moete
napraviti kostur uvoda sa ispravnim sintaksama i mestima za
sve opcije koje elite u standardnom uvodu. Kostur bi bio
"uzorak" koji sauvamo u fajl ili makro same strukture. Kada
napravimo novu rutinu, lako moemo ubaciti uzorak u izvorni
52

kod. Ako radimo na grupnom projektu, uzorci su laki nain da

ohrabrimo dosledno kodiranje i dokumentacione stilove.
Uzorke treba da su dostupni celom timu na poetku projekta, a
oni e ih koristiti, jer im olakava posao. Kao sporednu korist
dobijamo doslednost pri kodiranju.
f) Alati za pregled (browsing): Ova grupa alata takoe pomae
u pregledanju izvornog koda. Editori dozvoljavaju slinu
funkciju, ali brauzeri imaju drugaiju ulogu.

brauzeri: Neki alati su napravljeni specijalno za brauzing.

Oni su korisni za pravljenje doslednog seta promena
(osigurava da ste uzeli u obzir sve to se odnosi na rutinu
ili promenljivu, npr.). Dobar brauzer pretrauje i zamenjuje
deo izvornog koda kako u jednom tako i u vie fajlova
istovremeno. Brauzer moe da nae sve fajlove koji sadre
reference na odreenu promenljivu ili pokae svaku liniju
koja poziva rutinu. On moe da radi sa svim fajlovima u
projektu kao i svim fajlovima odreenog imena. Brauzer
moe inteligentno da trai promenljive i imena rutina.

Alati koji trae stringove u vie razliitih fajlova: Jedna

specifina vrsta brauzera moe u vie fajlova da trai
pojavljivanje odreenih stringova. Moete ih koristiti da
trae sva pojavljivanja globalnih promenljivih ili imena
rutina. Moete ih koristiti da naete sve fajlove na kojima
je odreeni programer radio. Kad pronaete greke u kodu,
moete ih koristiti da proverite da li ima greaka i u ostalim
fajlovima. Moete traiti tane nizove, sline nizove
(ignoriui razlike zbog velikih slova) ili regularne izraze.
Regularni izrazi su naroito moni, jer dozvoljavaju
pretrage za pojedinim delovima sloenog niza.

Generatori strukture poziva: Oni produkuju informacije

o rutinama koje se meusobno pozivaju. Ovo je ponekad
korisno pri otklanjanju greaka ali se ee koristi za
analiziranje programske strukture ili pakovanje programa u
module. Neki generatori daju obimne listinge svih poziva
od strane svih rutina. Drugi daju dijagram koji pokazuje
sve pozive proizale iz prve rutine u programu. Neki opet
belee pozive jedne rutine prema svim ostalima i obrnuto
(bilo direktno ili indirektno).

g) Analiziranje kvaliteta koda: Alati ove kategorije ispituju

statiki izvorni kod da procene njegov kvalitet.

Alati za proveru sintakse i simantike: Oni dopunjuju

kompajler temeljnije proveravajui kod nego to to
kompajler inae radi. Kompajler moe samo proveravati da
li ima osnovnih greaka sintakse. Probirljivi alat za proveru
53

sintakse moe koristiti jezike nijanse da proveri ima li

perfidnijih greaka (stvari koje sa kompajlerove take
gledita nisu pogrene, a vi verovatno niste nameravali da
napiete). "Lint" je probirljivi alat koji moete nai u
mnogim C okruenjima. Lint upozorava na neinicirane
promenljive,
potpuno
nekoritene
promenljive,
promenljive kojima su dodeljene vrednosti, a nikad nisu
koritene, sumnjiva logika poreenja i mnoge druge
uobiajene probleme.

Alati za proveru metrike: Neki alati analiziraju kod i

izvetavaju o njegovom kvalitetu. Na primer, moete da
kupite alate koji izvetavaju o sloenosti svake rutine tako
da moete da izaberete najkomplikovanije rutine za ekstra
pregled, testiranje ili redizajn. Neki alati broje linije koda,
deklaracije podataka, komentare, prazne linije bilo u celom
programu bilo u pojedinanim rutinama. Oni prate defekte
i povezuju ih sa programerom koji ih je nainio. Takoe
mogu da prate promene koje ispravljaju defekte u kodu i
programere koji su uradili ispravke. Ovi alati mogu da
broje svaku modifikaciju softvera kao i da pamte rutine
koje su najee bile modifikovane.

h) Prestrukturiranje izvornog koda: Postoji i niz alata koji

pomau u konvertovanju izvornog koda iz jednog formata u
drugi format:

Alati za restrukturiranje: Oni moraju da prave mnogo

pretpostavki i ako je logika loa u originalnoj verziji
programa, bie loa i u promenjenoj verziji programa
(recimo kada menja kod koji sadri GOTO naredbu). Ako
konvertovanje radite runo, moete koristiti ove alate za
uoptene sluajeve, a tee sluajeve radite runo.
Alternativa je da propustite kod kroz "restructurer" i
dobijeni rezultat iskoristiti za runo konvertovanje.

Prevodioci koda: Ovo su alati koji prevode kod iz jednog

jezika u drugi. Prevodilac je koristan kada imate veliku
bazu koda, koju prenosite u drugo okruenje. Rizik
korienja jezikih prevodilaca je isti kao i kod
restrukturera: ako u startu imate lo kod, ovakav alat e ga
jednostavno prevesti u lo kod u novom okruenju.

i) Renici podataka: To su baze podataka o imenima

promenljivih u programu sa opisima istih. U velikim
projektima korisni su za praenje hiljada definicija
promenljivih u sistemu. Na projektima u kojima se koriste
baze podataka, ovi alati mogu biti od velike pomoi za
opisivanje podataka sauvanih u bazi. Na timskim projektima
dobri su za izbegavanje kolizije imena. Kolizija moe biti
54

direktna, u kom sluaju se isto ime koristi dva puta, ili moe
biti suptilnija gde razliita imena oznaavaju isti element.
Renik podataka sadri ime, tip i atribute svake promenljive.
Takoe, moe sadravati beleke o tome kako je promenljiva
koriena. U vie-programerskom okruenju renik bi naravno
trebao biti dostupan svim programerima.

3.3 Alati izvrnog koda

Alati za rad sa izvrnim kodom su jednako bogati kao i alati za
rad sa izvornim kodom.

3.3.1 Formiranje koda

Alati opisani u ovom odeljku pomau pri kreiranju koda
a) Linkeri: Standardni linkeri povezuju jedan ili vie objektnih
fajlova (koje je kompajler generisao iz vaih izvornih fajlova), sa
standardnim kodom neophodnim za pravljenje izvrnog
programa. Linkeri vee snage mogu povezivati module pisane na
vie razliitih jezika (dozvoljavajui vam da za svaki deo vaeg
programa odaberete jezik koji mu najvie odgovara), a da ne
morate sami da rukujete detaljima integracije. Overlay linkeri
kreiraju izvrne fajlove koji omoguavaju da se samo pojedini
njihovi delovi uitavaju u memoriju, a ostatak koda ostaje na
disku dok ne bude potreban.
b) Programske biblioteke: Na tritu postoji mnotvo
kvalitetnih gotovih bibilioteka kodova iz raznih oblasti. Dakle,
nema potrebe da sami piete kompletan kod. Moete da
koristite tj. kupite ve uraene gotove biblioteke. U nastavku je
navedeno nekoliko oblasti za koje na tritu postoje gotove
biblioteke:
unos znakova pomou tastature i mia

kreiranje Windows korisnikog interfejsa

izlaz za ekrane i tampae

sloene grafike funkcije

kreiranje multimedijalnih aplikacija

mree

editovanje i procesiranje teksta

matematike operacije

kompresija podataka

itd

c) Generatori koda: Ako ne moete da kupite kod koji elite,

moete da kupite alate koji piu kod umesto vas. Alati
generisanja koda se koncentriu na aplikacije vezane za baze
podataka, ali to ukljuuje mnogo aplikacija. Dostupni

55

generatori piu kod za bazu podataka, korisniki interfejs i

kompajlere. Kod koji oni generiu retko je dobar kao kod koji
napravi programer, ali mnogi delovi aplikacija su rutinski i
unificirani i ne zahtevaju runo pisanje koda. Generatori su
takoe korisni za pravljenje prototipova proizvoljnog koda.
Pomou generatora moete za nekoliko sati napraviti prototip
koji demonstrira kljune aspekte korisnikog interfejsa ili
moete eksperimentisati sa raznim dizajnerskim pristupima. Za
toliko funkcionalnosti, runim kodiranjem bi trebalo sigurno
nekoliko nedelja.
d) Makro predprocesori: Ova orua dozvoljavaju kreiranje
jednostavno imenovanih konstanti, ali takoe dozvoljavaju i
kreiranje komplikovanijih funkcionalnih zamena bez ikakvih
naruavanja rada u realnom vremenu. Npr. ako koristite
konstantu MAX_EMPL koja zamenjuje broj 5000 zaposlenih,
predprocesor e zameniti ovu vrednost pre nego to kod bude
kompajliran.
Ova orua pruaju prednosti u itljivosti i u mogunosti
modifikovanja. Prednosti u modifikovanju imate, jer ste stavili
ceo kod na jedno mesto gde ga lako moete menjati.
Predprocesorske funkcije su dobre za otklanjanje greaka, jer
su lake za prebacivanje iz radnog u razvojni kod. Ako u toku
razvoja, elite da proverite memorijsku fragmentaciju na
poetku svake rutine, moete koristiti makro na poetku istih.
Ako provereno ne elite da ostavite u radnom kodu,
redefiniite makro proizvodnog koda tako da uopte ne
generie bilo kakav kod. Zbog slinih razloga, MAKRO-i su
dobri za pisanje koda koji je predvien za kompajliranje u
raznim okruenjima (na primer i u MS-DOS i u UNIX).

3.3.2 Podeavanje koda

Ovi alati pomau u dodatnom poboljanju koda.
Izvrni profajler
On posmatra kod dok je u radu i daje informacije o tome
koliko je puta svaki iskaz izvren ili koliko vremena program
troi na svaki iskaz. Profiliranje koda dok je u radu prua uvid
u to kako program radi, gde su mu slabe take i gde bi trebalo
da skoncentriemo svoje napore u poboljanju koda.

Asemblerski listinzi i Disasembleri

Neki jeziki kompajleri visokog nivoa generiu asemblerske
listinge. Drugi to ne rade, tako da morate koristiti disasembler
da bi iz mainskog koda koji kompajler generie ponovo
kreirali asemblerski. Gledanje u asemblerski kod generisan
kompajlerom pokazuje koliko efikasno kompajler prevodi
jeziki kod visokog nivoa u mainski kod.

56

3.4 Alatno-orijentisano okruenje

U nekim programskim okruenjima moe se uoiti bolja
prilagoenost u programiranju uz pomo raznih pomonih alata. Ovaj
odeljak se bavi sa tri karakteristina okruenja i to:
a) UNIX: Okruenje je poznato po svojoj kolekciji malih alata
koji zajedno odlino funkcioniu. C jezik, blisko uparen sa
UNIX-om uspostavlja filizofiju programiranja malim, otrim
alatima. Standardna C biblioteka je sastavljena od malih
funkcija koje se lako mogu ukomponovati u vee funkcije.
b) CASE: Case je
akronim za "computer-aided software
engineering". Idealan CASE alat je program koji snabdeva end
to end podrkom za softverske razvojne aktivnosti: analiza
uslova, arhitektura, detaljan dizajn, kodiranje, debaging,
testiranje jedinice, testiranje sistema, odravanje. CASE alat
koji obezbeuje praktinu podrku za svaku od ovih aktivnosti
bi zaista bio moan alat. Na alost, veina CASE alata ima
stanovite nedostatke

podravaju samo deo razvojnog ciklusa

podravaju sve delove, ali su u nekim podrujima suvie

slabi da bi bili od koristi

njihova podrka razliitim delovima nije integrisana

zahtevaju previe trokova

iskljuivo se fokusiraju na jednu metodologiju.

c) APSE: APSE je akronim za "ada programming support

environment". Cilj je da obezbedi integrisani set alata podrke
za programiranje u Ada jeziku, sa akcentom na softvere za
ugraene aplikacije. Ministarstvo odbrane SAD-a je definisalo
grupu kapaciteta koje APSE mora imati, ukljuujui:
alate kreiranja koda (osetljivi programerski ADA editor,
printer, kompajler)

alate analize koda (statiki i dinamiki analitiari koda,

merai performansi)

alate odravanja koda (administrator fajla, konfiguracijski

menader)

alate podrke projekta (dokumentacioni sistem, sistem

kontrole projekta, sistem kontrole konfiguracije, sistem
izvetavanja o grekama, alati dizajna).

57

3.5 Pravljenje sopstvenog alata za

programiranje
Sa nekoliko izuzetaka, i manji tim programera moe napisati
veinu alata opisanih u ovom poglavlju jer ne postoje tehnike barijere
za tako neto.
a) Alati specifini za projekat: Veina srednjih i velikih projekata
zahteva specifine alate, jedinstvene za sam projekat koji nisu
univerzalno primenljivi. Na primer moe nam zatrebati alat koji e
kreirati specijalnu vrstu test podataka da bi potvrdili tanost i
kvalitet izlaznih podataka, ili alat koji e simulirati hardver koji
nije trenutno dostupan itd.
b) Skriptovi: To su alati koji automatizuju poslove koji se
ponavljaju. U nekim sistemima skriptovi se nazivaju "batch"
fajlovi ili macro-i. Skriptovi mogu mogu biti jednostavni i
sloeni, a neki od najkorisnijih su i najlaki za pisanje. U nastavku
emo navesti primer Word-ovog dokumenta koji je lozinkom
zatien za pristup osim kada odreena osoba radi na njemu.
Da bi se osigurao da je uvek pravilno ifriran i deifriran, autor je
napravio skript koji deifrira fajl, izvrava word-procesor, a po
zavretku rada na dokumentu ponovo postavlja lozinku. %1 je
polje njegove lozinke.
crypto c:\word\journal.* %1 /d /Es /s
word c:\word\journal.doc
crypto c:\word\journal.* %1 /Es /s

Primer

60. Primer skrita za ifrovanje i deifrovanje Word-ovog

dokumenta

c) Alati koji poboljavaju "batch"-fajlove: "Batch" fajl je ASCll

tekstualni fajl koji sadri sekvence sistemsko-operativnih
komandi, ukljuujui komande podrane od strane "batch" jezika.
Nisu svi "batch" jezici kreirani jednako, jer su neki mnogo moniji
od ostalih. Ako se naete u situaciji da koristite slab "batch" jezik,
potraite alate koji pojaavaju "batch" fajlove. Dae vam snanije
"paketne" sposobnosti, nego standardni "batch" jezik koji ide uz
va kompjuter.

3.6 Idealno programsko okruenje

Idealno programsko okruenje nazivamo "Cobble" (obuar), a
po staroj prii da su obuareva deca poslednja koja dobiju nove cipele.
U ovom poglavlju baviemo se programerskim okruenjem koje je
ini se, na dohvat ruke dananje tehnologije, a koje bi moglo
podravati itav niz bitnih karakteristika i funkcija.
58

a) Integracija: Idealno okruenje integrie programske aktivnosti

detaljnog dizajna, kodiranja i otklanjanja greaka. Kada je
potrebna kontrola izvornog koda, obuar integrie verzionu
kontrolu izvornog koda. Ako se slede preporuke za detaljan dizajn
preporuene u 3. poglavlju, jedini potreban alat je PDL (program
design language) (jer se njime lako rukuje ak i u tekstualnim
okruenjima).
b) Jezika podrka: Tokom konstrukcije koda, obuar obezbeuje
spreman pristup "pomoi sa uputstvima" za jezik programiranja.
"Pomo" objanjava nijanse jezika i spominje uobiajene
probleme u korienju stavki tog jezika. Okruenje obezbeuje
ablone za jezike konstrukcije, tako da ne morate pamtiti tane
sintakse za CASE iskaze, FOR petlje ili jo manje uobiajene
konstrukcije.
c) Detaljna uputstva: Obuar daje mogunost da napravimo listu
svih mesta na kojima je promenljiva koritena ili prima vrednost.
Pomo za deklaraciju promenljive moemo dobiti lako kao i
pristup definiciji promenljive i komentare o njoj. Istom lakoom
moete doi do informacija o rutinama.
d) Interaktivni pregled programske organizacije: Kompajleri
itaju izvorne fajlove od poetka prema kraju i tradicionalna
razvojna okruenja primoravaju da pregledate program na isti
nain (sekvencijalan i ravan). U obuaru, moete pregledati
grafiki prezentovane vorove imena rutina, sa mogunou
zumiranja bilo koje. Moete pregledati samo definiciju rutine ili
samo komentarski uvod svake rutine. Moete pregledati kontrolne
strukture sa ili bez prikazivanja koda koji kontroliu. U jezicima sa
makro komandama, moete pregledati program sa rairenim ili
skupljenim makroima.
e) Interaktivno formatiranje: Obuar obezbeuje aktivniju pomo
u odnosu na postojea okruenja pri formatiranju. Okruenje
formatira kod prema parametrima specifinim za korisnika. U
kobleru ne morate pribegavati odvojenom programu da biste
formatirali kod. Neka dananja okruenja pruaju slabu podrku
automatskom uvlaenju kontrolnih struktura. Idealno okruenje
formatira kod prema njegovoj logikoj strukturi. Ako promenite
logiku strukturu, okruenje shodno tome ponovo formatira kod.
f) Dokumentacija: Kobler podrava tradicionalno komentarisanje i
nudi izbor u nivou komentara koje prikazuje. Takoe podrava
glasovne beleke, kao i hipertext linkove za vanije odeljke vezane
za dizajn dokumenta kao i sistemske zahteve.
g) Podeavanje performansi: Obuar automatski sakuplja podatke
vezane za metriku i proraunava performanse potrebne za fino
59

podeavanje. Na primer: na kom mestu program koristi 90% svog

vremena, koji deo koda se nikad ne izvrava, koji deo programa
ima najsloeniju logiku, koji delovi programa su stabilni a koji
naruavaju stabilnost itd. Sve ove informacije su veoma vane i
korisne za unapreenje samog dizajna.
h) Karakteristike okruenja: U obuaru su editovanje,
kompajliranje i debaging integrisani u jedno okruenje. U toku
razvoja programa, moete ga izvravati, menjati mu delove i
nastaviti izvravanje bez menjanja stanja u kome se program
nalazio pre nego to ste nainili promene. Kobler prepoznaje koji
delovi programa zavise od kojih drugih delova i rekompajlira ih po
potrebi. Konano, kobler podrava revolucionarno razlikovanje
izmeu razvojnog i produkcionog koda. Akcenat je na
detektovanju i otklanjanju greaka to je bre i bezbolnije mogue.
Tokom razvoja, kobler detektuje i belei uobiajene probleme, a
kompajler lako ubacuje ekstra kod da proveri te probleme.

REZIME:

Dobri alati umnogome olakavaju ivot programera pri pisanju

koda

Mnoge od alata koji su vam potrebni moete sami napraviti

Velika prednost pri programiranju je direktna posledica razvoja

sadanje tehnologije

60

4. UTICAJ VELIINE PROGRAMA

NA KONSTRUKCIJU
SOFTVERSKIH PROJEKATA
Poveavanje opsega u softverskom razvoju nije samo uzimanje
malog projekta i poveavanje svakog njegovog dela. Pretpostavite da
ste za 6 meseci napisali Gigatron softverski paket od 5000 linija i na
testiranju nali 25 greaka. Recimo da sada ponete da radite na
pojaanoj verziji programa u kojoj se oekuje 50000 linija koda. Iako
je 10 puta vei od originalnog Gigatrona, na razvoju Gigatrona de luxe
nee trebati 10, ve 20 puta vei napor. ta vie, 20 puta vei napor ne
podrazumeva 20 puta vie konstruisanja. Verovatno podrazumeva 12
puta vie konstruisanja i 40 puta vie integrisanja i sistemskog
testiranja. Ako ste navikli da radite na malim projektima, va prvi
srednji - ka - velikom projekat bi se mogao oteti kontroli. Nasuprot
tome, ako ste navikli na rad na velikim projektima, na prvom malom
mogli biste koristiti pristupe koji su suvie formalni. Ovo poglavlje
opisuje kako da ekonomiete, da biste spreili uruavanje projekta pod
teretom trokova.

4.1. Radijus veliina projekta

irok radijus veliina projekata znai da ne moete jednu veliinu
smatrati tipinom. Jedan nain razmiljanja o veliini projekta je da
razmiljate o veliini tima koji radi na njemu. Sledi gruba procena u
procentima svih projekata raenih od strane timova razliitih veliina:
PROCENAT
PROJEKATA
1-3
50%
4-8
33%
8-12
6%
12-20
5%
20-50
3%
50+
2%
Evo jo jedne tabele u kojoj moemo videti grubu procenu u
procentima svih programera koji rade na projektima razliitih veliina:
VELIINA TIMA

VELIINA PROGRAMA
IZRAENA U LINIJAMA KODA
2K
2K - 16K
16K - 64K
64K - 512K
512K+

61

PROCENAT
PROGRAMERA
5 - 10 %
5 - 10 %
10 - 20%
30 - 40%
30 - 40%

4.2. Uticaj veliine projekta na razvojne

aktivnosti
Ako sami radite na projektu, Vi imate najvei uticaj na uspeh
ili propast projekta. Ako radite na projektu sa 25 osoba, vae
organizovanje e imati najvie uticaja na uspeh ili propast projekta.

4.2.1 Komunikacija i veliina

Ako ste jedina osoba u projektu, jedini komunikacioni put je izmeu
vas i kupca. Broj komunikacionih puteva se poveava zajedno sa
brojem osoba ukljuenih u projekat. Broj se ne poveava sabiranjem
ve mnoenjem, proporcionalno kvadratu broja ljudi na projektu
(pod uslovom da osoba komunicira sa svakom od ostalih osoba). 2%
projekata koji imaju 50 ili vie programera imaju najmanje 1200
potencijalnih komunikacionih staza. to vie staza imate, vie
vremena provodite komunicirajui i vie prilika se stvara za
komunikacione greke. Vei projekti zahtevaju organizacione
tehnike koje usmeravaju komunikaciju ili je razumno ograniavaju.
Tipian pristup za usmeravanje komunikacija je formalizovanje istih
preko dokumenata. Umesto da imate 50 ljudi koji priaju
meusobno u svakoj zamislivoj kombinaciji, imaete 50 ljudi koji
itaju i piu dokumenta. Neki su tekstualni dokumenti, neki su
grafiki, a neki su zadrani u elektronskoj formi. Evo ilustracije na
ovu temu:

komunikacioni putevi
izmeu dva programera

komunikacioni putevi
izmeu tri programera

komunikacioni putevi
izmeu pet programera

komunikacioni putevi
izmeu etiri programera

Zamislite sami kako bi ova slika izgledala da imamo 10 ili vie

programera na projektu!?

62

4.2.2 Proporcija aktivnosti i veliina

Kako raste veliina projekta i potreba za formalnom
komunikacijom, vrste aktivnosti potrebne projektu dramatino se
menjaju. Sledi grafikon koji pokazuje proporcionalnosti razvojnih
aktivnosti za projekte razliitih veliina:

100 %

Integracija

Procenat
vremena
razvoja
kodiranje i ispravljanje greaka

Konstrukcija

detaljan dizajn
Arhitektura

0%
2K

8K

32 K

128 K

Veliina koda u linijama koda

Na malom projektu, konstrukcija je najistaknutija aktivnost i
zauzima do 80% ukupnog razvojnog vremena. Na projektu srednje
veliine, konstrukcija je jo uvek dominantna aktivnost, ali njen deo
pada na oko 50%. Na veoma velikim projaktima, arhitektura,
integracija i testiranje sistema zauzimaju isto vremena kao i
konstrukcija. Ukratko, kako se veliina projekta poveava,
konstrukcija postaje manji deo ukupnih napora. Konstrukcija postaje
manje dominantna zbog poveanja veliine projekta konstrukcione
aktivnosti (detaljan dizajn, kodiranje, otklanjanje greaka, testiranje
jedinice) poveavaju se linearno, ali mnoge druge aktivnosti
umnoavaju. Ako je jedan projekat dva puta vei od drugog, trebae
duplo napora u konstruisanju, ali 4 puta vie u integrisanju i
sistemskom testiranju. Aktivnosti koje rastu vie nego linearnom
stopom, kako se veliina projekta poveava, su:

63

512 K

planiranje

menadment

komunikacija

razvoj uslova

funkcionalni dizajn sistema

dizajn interfejsa i specifikacija

arhitektura

integracija

otklanjanje defekata

testiranje sistema

proizvodnja dokumenata

Bez obzira na veliinu projekta, neke tehnike su uvek vredne:

strukturalno kodiranje, logika i inspekcija koda od strane drugih
programera, on-line razvoj sistema podrke,i upotreba jezika
visokog nivoa. Na velikim projektima, tehnike same po sebi moda
nee biti dovoljne, ali nisu protraene na manjim projektima.

4.2.3 Metodologija i veliina

poeni
kategorija

1.

ne,
reprogramira
zahtev za
originalnou se na drugoj
opremi

minimalna

ograniena,
primenjuje
se novi
interfejs u
novom

umeren

veliki

64

ocena

Metodologije se koriste na projektima svih veliina. Na malim

projektima su neformalne i instiktivne. Na velikim projektima su
rigorozne i paljivo planirane. Neke metodologije mogu biti tako
labave da programeri nisu ni svesni da ih koriste. Neki programeri
tvrde da su metodologije suvie krute. Dok je moda tano da
programer nije svesno izabrao metodologiju, svaki pristup
programiranju konstituie metodologiju, bez obzira koliko je pristup
nesvestan ili primitivan. Formalni pristupi nisu uvek zabavni i ako
su pogreno primenjeni, opti trokovi e im prevazii druge utede.
Vea sloenost velikih projekata zahteva veu svesnu panju na
metodologiju. Nesvesni izbori su nedorasli zadacima velikih
projekata. Uspeni planeri projekata eksplicitno biraju strategije za
velike projekte. Ministarstvo odbrane USA je razvilo jedan metod
odreivanja stepena formalnosti potrebne za projekat. Njihov pristup
po pitanju formalnosti ukljuuje bodovanje programskog projekta na
bazi dodeljivanja poena u svakoj od 12 kategorija:

okruenju
ogranien

ograniena
fleksibilnost

fleksibilan
format, za
vie
ciljeva

veoma
fleksibilan,
multi
platformski
odseci
ministarstva
irom sveta

2.

nivo optosti

strogo
ogranien,
samo za
jednu svrhu

3.

raspon
operacija

lokalna

deo
komande

jedna
komanda

vie
komandi

4.

promena u
opsegu i
ciljevima

ne

retko

povremeno

frekventno

neprestano

vie maina,
standardni
periferni
sistem

vie
maina,
sloeni
periferni
sistem

vie maina,
oprema za
automatski
ulaz-izlaz i
prikaz

5 - 10

10 - 18

18 i vie

5.

sloenost
opreme

jedna
maina

jedna
maina
proirena
perifernim
sistemom

6.

broj uesnika
u projektu

1-2

3-5

7.

veliina
projekta

8.

kritine take

9.

10.

modifikacija
posle
proseno
unos
podataka
posle
proseno

3 - 15 K

15 - 70 K

70 - 200 K

200-500 K 500 K i vie

procesiranje
podataka

rutinske
operacije

lina
bezbednost

opstanak
jedinice

nacionalna
odbrana

2 i vie
nedelja

1-2
nedelje

3 - 7 dana

1 - 3 dana

svakodnevn
o

2 i vie
nedelja

1-2
nedelje

1 - 7 dana

1 - 24 asa

9 - 60
minuta
(interaktivn
o)

vii
programski
jezici i
ograniena
upotreba
asemblera

vii
programski
jezici i ira
upotreba
asemblera

asembler

mainski
jezik

ogranieno

umereno

srednje

jako

11.

programski
jezici

vii
programski
jezici

12.

softver je
razvijen kao
konkurentski

ne

ukupno
Program moe biti bodovan od 12-60 poena. Ocena 12 znai da su
zahtevi projekta lagani i da je potrebno malo formalnosti. Ocena 60,
znai da je projekat ekstremno zahtevan i da mu je potrebno to je
mogue vie strukture. U softverskom razvoju, to je projekat
formalniji, vie papira morate generisati da se uverite da ste uradili
domai. Dokumentaciju o projektu ne kreirate zbog nje same, ve
ona treba da vas natera da paljivo planirate i svoj plan objasnite
svima ostalima. Dokumentacija je opipljiv propratni efekat pravog
posla koji radite dok planirate i konstruiete softverski sistem.

65

4.2.4 Programi, proizvodi, sistemi i sistemski

proizvodi
Linije koda i veliina tima ne utiu jedini na veliinu projekta.
Suptilniji uticaj imaju kvalitet i sloenost finalnog softvera.
Najjednostavnija vrsta softvera je jedan "program" koji koristi sama
osoba koja ga je razvila ili nekolicina drugih ljudi.
Sofisticiranija vrsta programa je softver "proizvod", program koji je
namenjen da ga koriste drugi ljudi osim originalnog programera.
"Proizvod" se koristi u okruenjima koja se manje ili vie razlikuju
od okruenja u kojem je kreiran. Obimno je testiran pre nego to je
puten, dokumentovan je i sposoban da ga drugi odravaju. Softver
"produkt" je tri puta skuplje razviti nego softver "program". Drugi
nivo sofistikacije je potreban da bi se razvila grupa programa koji
rade zajedno. Takva grupa se zove softver "sistem". Razvoj sistema
je komplikovaniji nego razvoj programa zbog sloenosti razvoja
interfejsa u delovima i neophodne paljivosti u integraciji delova. U
celosti, sistem takoe kota oko tri puta skuplje od programa.
Kada je "sistemski proizvod" razvijen ima finalizaciju "produkta" i
viestruke delove sistema. Sistemski proizvod kota oko devet puta
skuplje od obinog programa. Uobiajen razlog greaka u proceni je
kada se ne cene razlike u finalizaciji i sloenosti meu programima,
proizvodima, sistemima i sistemskim proizvodima.
Programeri koji koriste svoje iskustvo, u pravljenju programa, da
procene raspored za gradnju sistemskog produkta, mogu taj raspored
da podcene skoro do faktora 10.
Sledei primer se odnosi na grafikon na strani 58:
Ako ste u pisanju 2K linija koda koristili svoje iskustvo da procenite
vreme potrebno za razvoj 2K programa, vaa procena e biti samo
80% od ukupnog potrebnog vremena za obavljanje svih aktivnosti
koje ulaze i razvoj programa. Pisanje 2K linija koda ne traje toliko
dugo koliko je potrebno za kreiranje programa koji sadri 2K linija
koda. Ako ne uzmete u obzir vreme potrebno za obavljanje
nekonstrukcionih aktivnosti, razvoj e trajati 25% due nego to ste
procenili. Kako se projekat poveava, konstrukcija postaje manji deo
ukupnih napora u projektu. Ako svoje procene bazirate iskljuivo na
konstrukcionom iskustvu, greke u proceni se poveavaju. Ako ste
koristili sopstveno 2K konstrukciono iskustvo da procenite vreme
potrebno za razvoj 32K programa, vaa procena e biti samo 50%
ukupnog vremena. Razvoj bi zahtevao 100% vie vremena nego to
ste procenili. Za ovu greku u proceni biste u potpunosti imali da
zahvalite vaem nerazumevanju efekta veliine u razvoju veih
programa. Ako u prilog tome ne biste uzeli u obzir da, za razliku od
jednostavnog programa, produkt zahteva vei nivo "poliranja",
greka bi lako mogla da se povea i do faktora 3 ili ak i vie.

4.3. Efekat veliine projekta na greke

Veliina projekta utie i na koliinu i na vrstu greaka. Moete
pomisliti da nee uticati na vrstu greaka, ali kako se veliina projekta
66

poveava, vei procenat greaka se pripisuje po grekama u analizi i

dizajnu. Na malim projektima, konstrukcione greke ine 75% svih
pronaenih greaka. Metodologija ima manji uticaj na kvalitet koda, a
najvei uticaj na kvalitet programa ima vetina individualnog pisanja
programa. Na velikim projektima konstrukcione greke se sputaju do
50% ukupnih greaka. Razliku sainjavaju analitike i arhitekturne
greke. Pretpostavlja se da je to povezano sa injenicom da vei
projekti zahtevaju vie analiza i arhitekture, tako da se prilike za
greke u ovim aktivnostima proporcionalno poveavaju. Meutim, na
nekim veoma velikim projektima (500 000 linija koda) proporcija
konstrukcionih greaka ostaje visoka, i do 75% se pripisuje
konstrukciji. Kako se sa veliinom menja i vrsta defekata, menja se i
njihov broj. Prirodno je da oekujete da dva puta vei projekat ima
dva puta vie greaka. Uestalosta defekata (broj greaka po liniji
koda) se, meutim, poveava. Tabela na sledeoj strani pokazuje
radijus oekivanih uestalosti defekata na projektima razliitih
veliina. Podaci o ovoj tabeli su dobijeni iz specifinih projekata i
mogu imati malo slinosti sa projektima na kojima ste vi radili.
Meutim, podaci pokazuju da se broj greaka dramatino poveava sa
veliinom projekata, tako da veoma veliki projekti imaju i do 4 puta
vie greaka po liniji koda od malih projekata. Podaci takoe,
impliciraju da je do odreene veliine mogue napisati kod bez
greaka, a preko te veliine, greke se pojavljuju bez obzira na namere
koje ste preduzeli da ih spreite.
veliina projekta
(izraena brojem
linija)
manji od 2K
2K - 16K
16K - 64K
64K - 512K
512K i vie

uestalost greaka
0 0 0.5
2 4 -

25 greaka na hiljadu linija koda

40 greaka na hiljadu linija koda
- 50 greaka na hiljadu linija koda
70 greaka na hiljadu linija koda
100 greaka na hiljadu linija koda

4.4. Efekat veliine projekta na

produktivnost
Kada se radi o veliini projekta, produktivnost ima mnogo toga
zajednikog sa kvalitetom softvera. Na manjim veliinama (2000
linija koda ili manje), najvei pojedinani uticaj na produktivnost ima
individualna vetina programera. Kako se veliina poveava, veliina
tima i organizacija imaju vei uticaj na produktivnost. Po Boemu,
Greju i Sivoltu idealno je da tim ima dva oveka na malom projektu i
tri na veem. Preko toga, veliina tima bitno utie na produktivnost.
Tabela koju vidimo daje generalnu povezanost izmeu veliine
projekta i produktivnosti. U velikoj meri produktivnost je odreena
kvalitetom osoblja, jezikom programiranja, metodologijom,
sloenou proizvoda, programskim ambijentom, alatnoj podrci i
mnogim drugim faktorima, tako da podatke iz tabele uzmite sa malom
67

rezervom. Meutim, generalni trend koji brojke pokazuju je znaajan.

Produktivnost na manjim projektima je 10 puta vea od produktivnosti
na velikim. ak i ako biste sa programima od 1K linija koda preli na
program od 9K, mogli biste da oekujete pad produktivnosti za skoro
pola.
veliina projekta
(izraena brojem
linija)
manji od 2K
2 K - 16 K
16 K - 64 K
64 K - 512 K
512 K i vie

linije koda po mesecu

333
200
125
67
36

2000
1250
1000
500
250

REZIME
)

Aktivnosti koje se na malim projektima uzimaju zdravo za

gotovo, na velikim projektima moraju biti paljivo planirane

Kako se veliina projekta poveava, konstrukcija postaje manje

dominantna

Poveanjem veliine, komunikacije moraju biti usmerene.

Sutina veina metodologija je smanjenje komunikacionih
problema, i jedna metodologija bi trebala biti koritena ili ne, u
zavisnosti od toga koliko servisira komunikaciju.

68

5. UPRAVLJANJE
KONSTRUKCIJOM
SOFTVERSKIH PROJEKATA
Krajem dvadesetog veka upravljanje razvojem softvera je
postalo teak zadatak. U ovom poglavlju emo samo prodiskutovati
nekoliko specifinih tema o upravljanju softverskim projektima i
izradi softvera.

5.1 Ohrabrivanje dobrog kodiranja

Kljuno pitanje u izradi softvra je kako uvebati programere da
dobro kodiraju. Uspostaviti set standarda i slepo ih se drati nije ba
neka dobra ideja, ali nekih pravila i preporuka ipak mora biti.

5.1.1 Tehnike poveanja efikasnosti

programiranja
U nastavku je dato nekoliko saveta koji su se u praksi pokazali kao
dobri:
a) Programiranje u paru: Ako se drite ovoga moete biti sigurni
da o svakoj liniji koda, o njenoj uspenosti i itljivosti brinu bar
dva oveka to nikako ne moe biti loe.
b) Pregledajte svaku liniju koda: U pregledanju koda uvek
uestvuje programer koji je pisao kod i najmanje jo dve osobe.
To je korisno iz jednostavnog razloga to glavni programer moe
napustiti projekat, prei u drugu kompaniju, samim tim na
projektu e raditi i dalje ljudi koji su upueni i u projekat i u
kod. Na kraju, sama diskusija prilikom eventualnog zajednikog
pregledanja koda ili kasnije primedbe onih koji su ga pregledali
mogu uticati na poboljanje samog koda.
c) Zahtevajte potpis odgovornog lica: Bez obzira koliko je ljudi
radilo na projektu, neko mora biti odgovoran za uraeni posao.
Potpis glavnog programera ili nekog drugog odgovornog lica na
kraju listinga koda ili trebalo bi da pokazuje da je kod tehniki
ispravan i bez greaka.
d) Kroz primere treba pokazati oekivani kvalitet softvera:
Veliki deo dobrog upravljanja izradom softvera je da jasno
definiete osnovne ciljeve koje softver treba da ostvari. Jedan od
naina je da programere upoznate sa ranije dobro uraenim
projekatima. Na taj nain stavjamo do znanja kakav kvalitet
softvera oekujete.
e) Naglasite da je poeljno da listing koda bude javan:
Programeri su esto sujetni i smatraju da je kod koji oni piu
njihovo lino vlasnitvo. Meutim, u timskom radu ovakav
pristup je neodriv. Svaki deo koda nekog projekta mora biti
dostupan svim lanovima tima kojima je potreban prilikom
razvoja i na kraju pri pregledu koda.

69

f) Nagradite uspean projekat: Iskoristite sistem nagraivanja u

vaoj organizaciji da unapredite dobro kodiranje. Prilikom
nagraivanja vodite rauna o sledeem:
nagradite programera tako da on bude zadovoljan
vodite rauna o kriterijumu nagraivanja
Nagraeni kod mora stvarno biti izuzetno kvalitetan. Ako
nagradimo programera za koga ostali deo ekipe zna da ne radi
dobro samo emo napraviti dodatne probleme.

5.2. Upravljanje konfiguracijom

softverskih projekata
Softverski projekat je dinamian proces: kod, dizajn, zahtevi se
menjaju. ta vie, promene u zahtevima dovode do promena u dizajnu,
promena dizajna dovodi do jo vie promena koda i sluajeva prilikom
testiranja.

5.2.1 ta je upravljanje konfiguracijom?

Upravljanje konfiguracijom u stvari predstavlja kontrolu
promena koda. To je u stvari sistematizacija postupka promena u kodu
da bi sistem mogao da sauva svoj integritet tokom vremena. Kontrola
promena podrazumeva procenu predloenih promena, praenje
promena, pravljenje backup kopija itd.
Postoji dosta razloga zato je potrebna kontrola promena. U
timskom radu, ako se ne vodi rauna o ovakvoj kontroli, moe se
desiti da zavrite pisanje koda za neki deo samog dizajna koji je
moda ve eliminisan iz projekta. Moe se desiti da piete kod koji je
nekompatibilan sa novousvojenim dizajnom. Ako promene nisu
kontrolisane, moe se desiti da i vi i neko drugi ko radi na projektu,
menjate neke rutine u isto vreme, a takva kombinacija promena
verovatno e biti problematina. Kontrola promena pomae da
racionalnije iskoristite svoje vreme.
Upravljanje konfiguracijom softverskih projekata najkorisnije
je upravo programerima. Primenjeno na sofverske projekte uobiajeno
je da se upravljanje konfiguracijom zove SCM (Software
Configuration Management). U nastavku razmatramo neke od opcija u
implementaciji SCM.

5.2.2 Promene u dizajnu softvera

U toku samog razvoja softvera ubrzo ete doi na ideju kako
da poboljate sam dizajn. Ako meutim implementirate svaku
promenu koja Vam padne na pamet uglavnom ete se baviti samim
promenama, a kraj posla nee biti ni na vidiku. Evo nekoliko ideja
vodilja koje mogu pomoi za kontrolisanje promena dizajna:
a) Sledite formalne procedure za kontrolu promena: Kada
ustanovite formalne procedure i pridravate ih se, bie lake da
promene koje razmatrate budu u kontekstu globalnog
poboljanja samog projekta.

70

b) Ustanovite komisiju za kontrolu promena: Posao ove

komisije je da odvaja bitne od nebitnih promena. Dakle, svako
ko radi na projektu i ima predlog neke promene mora prvo
poslati zahtev komisiji. Komisija se periodino sastaje, pregleda
predloene promene i naravno odobrava ih ili odbacuje.
c) Grupiite zahteve za promenama u grupe: Vrlo je
primamljivo implementirati neku relativno laganu izmenu u toku
rada. Meutim, problem sa ovakvim nainom razmiljanja i
delovanja je u tome to neka dobra promena moe jednostavno
da se izgubi. Sve zavisi od obima posla: ako na primer u toku
rada na projektu 25% vremena prevedemo razmiljajui o sitnim
izmenama i sve ostale obaveze na projektu idu po planu
uspeemo, ali ako nam za takve promene treba 90% vremena, a
ve kasnimo sa projektom neto e sigurno ostati zaboravljeno tj.
neuraeno. Kada vreme poinje da nam istie nee biti bitno da
li je 5-ta planirana promena deset puta bolja od prve bitno e
nam biti da uradimo bar prve 3 promene pre isteka roka.
Reenje je naravno da napiemo sve ideje i predloge promena,
bez obzira koliko teke za implementiranje bile, i sauvamo ih
dok ne bude vremena za realizaciju. Zatim kada ih pregledate
kao grupu prvo implementirajte onu promenu koja je
najkorisnija i taj postupak primenjujte iterativno.
d) Procenite "trokove" svake promene: Bez obzira da li va
poslodavac, ef ili vi pokuavate da promenite sistem, procenite
vreme koje je potrebno da se promena izvri, ukljuujui i vreme
potrebno za pregled i testiranje celog sistema. Svi zainteresovani
moraju znati koliko su promene komplikovane i koliko vremena
e biti potrebno za njihovu implementaciju pa ak i ako se na
prvi pogled ini da je promena trivijalna.
e) Budite oprezni sa velikim promenama: Ukoliko va
poslodavac predlae neku sutinsku promenu, treba da vam bude
jasno da jo uvek niste zavrili sa zahtevima koje va softver
treba da zadovoljava. Prekinite sa radom na dizajnu i vratite se
zahtevima sve dok zahtevane promene budu manje, pa se tek
onda vratite dizajnu.

5.2.3 Promene u kodu softvera

U ovom delu emo opisati kako kontrolisati sam izvorni kod.
Ako, naime, promenite kod i pojavi se greka koja nije direktno
vezana sa poslednjom promenom verovatno ete poeleti da uporedite
novu i staru verziju koda, pa ak i neke starije verzije. Ovo i nije tako
teko ukoliko imate odgovarajui softver.
a) Softver za kontrolu verzija: Dobar softver za kontrolu verzija
softvera je toliko jednostavan, da gotovo neete ni primetiti da
ga koristite. Ovakav softver je naroito koristan kod timskih
projekata. Na primer, ako pregledate izvorni kod u nekom
pojedinanom fajlu, a neko drugi je fajl ve pregledao ovakav
softver e Vam to signalizirati i jednostavno neete imati
potrebu da ga proveravate. S druge strane, ako ipak morate da
pregledate fajl ovakav softver e od Vas zahtevati da objasnite
71

razloge koji e biti dostupni drugim ljudima koji rade na

projektu.
b) Backup plan: Planiranje backup-a nije novi koncept, normalno
je da va rad periodino sauvate i na nekom drugom mediju
osim na maini na kojoj radite.
Zato? Pa ima mnogo razloga: disk moe da se pokvari, vi ili
neko drugi sluajno moete obrisati vienedeljni rad,
nezadovoljni kolega ili neki drugi zaposleni moe namerno da
izvri sabotau. Osim toga ne treba potcenjivati poplavu, poar
ili lopove.
Dakle, preduzmite korake da bi ovakve situacije predupredili.
Planiranje backup-a treba da podrazumeva periodino kompletno
backup-ovanje sistema, odlaganje odabranog medijuma u
posebno skladite, kao i uvanje ostalih vanih segmenata rada:
dokumentacije, grafikona, beleaka kao dodataka vaem
izvornom kodu. Vaan aspekt samog backup plana je naravno i
njegovo testiranje. Pokuajte da uz pomo backup-a, restauirate
kompletan sistem da bi se jednostavno uverili da Va backup
sadri sve to je potrebno da bi uspeno povratili rad u sluaju
neke od gore navedenih nezgoda.
Na kraju, kada projekat bude gotov, arhivirajte ga. Napravite
kopije svega to je vezano za projekat, ali bukvalno svega i
uvajte ih na bezbednom mestu.

REZIME

Upravljanje konfiguracijom softvera treba da omogui pomo

samim programerima i minimizira trokove.

Morate proceniti efekte svake predloene promene.

Koristite softver za kontrolu verzija da bi olakali upravljanje

konfiguracijom.

Koristite softver za kontrolu verzija da bi smanjili probleme

koordinacije u timskim projektima.

Periodino pravite backup.

Testirajte uspenost same procedure backup-a.

Sve medije na kojima se nalazi backup periodino smetajte u

odvojeno skladite.

5.3. Procena plana konstrukcije softverskih

projekata
Na kraju dvadesetog veka upravljanje softverskim projektima
kao i procena samog obima i napora potrebnih da se projekat zavri
predstavlja veliki izazov. U ovom odeljku u kratkim crtama emo
predstaviti neka pitanja o kojima treba voditi rauna prilikom same

72

procene konstrukcije softverskog projekta i pokuati da na njih damo

kvalitetne odgovore.

5.3.1 Prilaz proceni

Samu procenu veliine kao i napora potrebnih za realizaciju
odreenog projekta moete da obavite na nekoliko naina:

koristite softver za planiranje

koristite nezavisne eksperte za procenu projekta

procenite pojedine delove projekta, a zatim ih spojite u celinu

obratite panju na iskustva iz prethodnih projekata

Evo jo nekoliko dobrih ideja o samom problemu procene projekata:

a) Odredite ciljeve: ta je to to procenjujete? Zato je procena
potrebna? Koliko precizna treba da bude procena da bi zadovoljila
ciljeve projekta?
b) Odredite vreme za procenu i isplanirajte ga: Procene donete
prebrzo su uglavnom netane procene. Ako treba da procenite
projekat veeg obima, raslanite ga, za svaki deo odvojte potrebno
vreme i posao e biti valjano uraen.
c) Formuliite softverske zahteve: Nema razloga da neko oekuje
od Vas da procenite vreme i koliinu potrebnog rada da bi se
zavrilo "neto" ako to "neto" uopte nije definisano. Odredite ta
softver treba da radi bar na poetku eksploatacije pre bilo kakve
procene.
d) Koristite nekoliko razliitih tehnika procene i uporedite
rezultate: Na poetku odeljka, kada smo govorili o samom prilazu
proceni, dali smo nekoliko razliitih prilaza. Nee svi prilazi dati
iste rezultate i zato probajte nekoliko njih. Prouite razlike u
rezultatima u zavisnosti od prilaza koji ste odabrali i izvucite
pouke.
e) Periodino ponovite procenu: Posle inicijalne procene, kako se
projekat menja i napreduje, biete u mogunosti da svoju procenu
zavretka projekta uradite bolje, a samim tim poboljate poetnu
procenu. Tanost Vae procene e biti sve bolja to se projekat
blii kraju.

5.3.2 Uticaj na plan

Najvei uticaj na plan softverskog pojekta svakako predstavlja
veliina programa koji treba napraviti. Naravno postoje i drugi faktori
koji posredno i neposredno takoe utiu na plan softverskog razvoja.
Evo samo nekih od tih faktora:

motivacija tima

kvalitet menadmenta

koliina koda koji se ponovo koristi

73

nivo programskog jezika koji se koristi (vii programski jezici vs

asembler)

esta promena zahteva

korisniko uee u formiranju zahteva

obim dokumentacije

ciljevi projekta

5.3.3 Procena vs kontrola

Za samo zavravanje softverskog projekta na vreme procena je
veoma vaan deo planiranja. Kada jednom odredite krajnji rok za
isporuku softvera i njegovu specifikaciju glavni problem je kako
kontrolisati ljudske i tehnike resurse da bi se vremenska ogranienja
ispotovala. U tom smislu sama poetna procena ima manju vanost
od uspenosti kontrolisanja resursa kako bi se sve odvijalo po planu.

5.3.4 ta ako kasnite?

Veliki broj softverskih projekata kasni i to je injenica. Po
nekim istraivanjima procenjeni planovi se ostvaruju u 20% - 30%.
Produenje roka obino nije mogue, a ako jeste iskoristite tu
mogunost. Ako nije probajte neto od sledeeg:
a) Proirite tim: Po nekim istraivanjima ukljuivanje novih ljudi u
projekat je obino neproduktivno. Novim ljudima treba vremena
da se upoznaju sa projektom, a vreme je upravo ono to nam
nedostaje. Poveavanje broja ljudi na nekom projektu takoe
uslonjava i problem komunikacije meu lanovima tima. Da
pojednostavimo: vie ljudi na projektu ne znai direktno da e
posao biti bre obavljen i o tome menaderi treba da vode rauna.
Meutim, ipak, pod nekim okolnostima dodavanje novih ljudi
kasnije u neki projekat moe dovesti do ubrzanja njegove
realizacije. Ovo je posebno primenljivo ako su sami zadaci
projekta strogo parcijalizovani i s tim u vezi se mogu dodeliti
ljudima koji se ne moraju upoznavati sa ostalim delovima
projekta.
b) Smanjite opseg samog projekta: Prilikom samog poetnog
planiranja poeljno je delove samog projekta interno obeleite sa
"obavezno", "poeljno", "opcionalno". Ukoliko doete u
vremenski cajtnot prvo izbacujete "opcionalne" delove, pa onda i
neke "poeljne" ukoliko ba morate i time direktno smanjujete
opseg projekta.

5.4. Metrika
Sam izraz "metrika" se odnosi na bilo koju jedinicu mere
vezanu sa razvojem softvera. Naveemo neke: broj linija koda, broj
defekata, broj defekata na hiljadu linija koda, broj defekata po
modulu, broj globalnih promenljivih, broj sati rada potrebnih za
realizaciju koda...

74

Naveemo dva pouzdana razloga zato koristimo metriku za nae

projekte:
a) Bilo kakva metrika je bolja nego nikakva: Metrika moda i nije
uvek dovoljno precizna, teko je i napraviti, vremenom e se
verovatno menjati ali vam daje mogunost da lake drite pod
kontrolom proces razvoja softvera i date mu dodatnu ozbiljnost i
teinu.
b) Argumenti protiv metrike su u stvari argumenti da je bolje ne
znati ta se zapravo dogaa u projektu: Kada koristite metriku
uvek ete saznati neto o projektu to do tada niste znali. Metrika
zapravo predstavlja prozor u razne aspekte projekta i u svakom
sluaju je bolje da je imate.
U sledeoj tabeli naveemo neke od metrika koje su se vremenom
pokazale kao korisne:
Veliina
ukupan broj napisanih linija koda
ukupan broj komentara

Opti kvalitet
ukupan broj defekata
broj defekata po rutini
prosean broj defekata na hiljadu
linija koda
broj greaka koje je detektovao
kompajler

ukupan broj deklaracija podataka

ukupan broj praznih linija
Produktivnost
broj radnih sati utroenih na
projektu
broj radnih sati utroenih na svaku
rutinu
koliko puta je svaka rutina
menjana
koliko je novca utroeno na
projekat
koliko novca je utroeno na jednu
liniju koda

Odravanje
broj parametara prosleenih
svakoj rutini
broj lokalnih promenljivih
korienih u svakoj rutini
broj poziva podrutina u svakoj
rutini
kompleksnost algoritma svake
rutine
broj linija koda u svakoj rutini

broj linija komentara u svakoj

rutini
broj deklaracija podataka u
svakoj rutini
koliko je novca potroeno po
broj praznih linija u svakoj rutini
defektu
broj GOTO naredbi u svakoj
rutini
broj ulazno izlaznih operacija u
svakoj rutini
Praenje defekata
teina svakog defekta
lokacija svakog defekta
nain na koji je svaki defekt ispravljen
osoba koja je odgovorna za svaki defekt
75

broj linija koji je bio ugroen ispravkom svakog defekta

broj sati utroenih na ispravku svakog defekta
proseno vreme potrebno za pronalazak defekta
proseno vreme potrebno za ispravku defekta
broj napravljenih pokuaja da se ispravi svaki defekt
broj novih greaka nastalih ispravkom drugih defekata
Tabela 1. Metrike korisne za izradu softverskih projekata

Sve ove metrike moete prikupiti uz pomo softverskih alata

koji su danas na raspolaganju. Ne morate odmah prikupljati sve
mogue metrike koje su na raspolaganju. Krenite od osnovnog skupa
metrika kao to su broj defekata, broj utroenih radnih sati, ukupnog
broja linija koda...
Nemojte koristiti metriku bez razloga. Definiite ciljeve,
odredite pitanja na koja treba da odgovorite da bi postigli ciljeve i na
kraju iskoristite metriku da bi doli do odgovora.

5.5. I programeri su ljudi

Sutina programerskog ivota i rada je veita borba u
uspostavljanju ravnotee izmeu kakvog takvog normalnog ivota i
kancelarijskog okruenja sa stalnim kontaktima sa saradnicima i
strankama. U ovom odeljku pokuaemo da predstavimo i prikaemo
programere kao obine ljude, a ne samo kao refleksiju njihovih
raunara.
a) Kako programeri provode vreme? Pored programiranja,
programeri vreme provode takoe i na sastancima, obuci, itanju
maila ili na kraju krajeva razmiljajui. Jedna od studija prikazuje
programersko vreme na nain dat u Tabeli 2:

izvorni
posao privatno
kod
konverzacija 4%
17%
7%
razgovor sa
1%
menaderom
telefon
2%
1%
itanje
14%
beleke
13%
odsutan
4%
1%
etnja
2%
2%
1%
ostalo
2%
3%
3%
ukupno
35%
29%
13%
aktivnost

sastanci obuka mail

3%

2%
1%
4%
7%

testiranje
tehnika
ukupno
ostalo
programa
uputstva
1%
32%
1%
2%

6%
6%

1%
1%
5%

2%

Tabela 2. Tabelarni prikaz kako programeri provode vreme

76

1%
2%

1%
1%

3%
18%
14%
15%
6%
11%
100%

Iako je studija iz gore navedene tabele relativno stara, ilustrativno

je da gotovo 30% vremena programeri provode na poslovima koji
nisu direktno vezani za sam projekat: etnja, lini poslovi i slino.
Dakle, i programeri etaju i to tri puta vie nego to itaju tehnika
uputstva i ak est puta vie nego to razgovaraju sa menaderom.
b) Varijacije u performansama i kvalitetu: Prilikom
programiranja, talenat samog programera kao i koliina uloenog
napora za pojedine projekte ogromno variraju od programera do
programera. U zavisnosti od samog kvaliteta programera i
njegovih individualnih sposobnosti dobijamo velike razlike u
samom kvalitetu napisanih programa, veliini programa kao i
same produktivnosti programera.
c) Individualne varijacije: Po jednoj studiji, u kojoj su prouavani
programeri sa prosekom 7 godina radnog iskustva, dolo se do
sledeih rezultata:

vreme provedeno za inicijalno kodiranje kod najboljih i

najloijih programera je u razmeri 20 : 1

vreme provedeno u dibagiranju programa je u razmeri 25 : 1 u

korist boljih programera

veliina samog koda je u razmeri 5 : 1 u korist boljih

programera

vreme izvravanja programa je u razmeri 10 : 1 u korist boljih

programera

Meutim, studija nije pokazala nikakvu korelaciju izmeu ranijeg

programerskog iskustva i kvaliteta koda i programerske
produktivnosti.
d) Timske varijacije: Ako postoje individualne razlike meu
programerima, normalno je da postoje i razlike u kvalitetu i
produktivnosti pri timskom radu. Logino je bolji programeri tee
da se udrue kako bi napravili kvalitetniji i produktivniji tim, i to
potvruju razne studije sprovedene 90-tih godina.
Sutina je jasna: ako ste u mogunosti da platite duplo vie za
kvalitetnije programere uradite to. Utedeete na brzini, program
e biti kvalitetniji, uopte produktivnost e biti bolja, a krajnji
korisnik zadovoljniji.
e) Programerska sujevernost: Menaderi programerskih projekata
nisu uvek svesni programerske sujete i sujevernosti, i esto svojim
zahtevima mogu da izazovu nezadovoljstvo samih programera koji
rade na projektu. Evo nekih pitanja sa kojima treba biti oprezan pri
postavljanju zahteva programerima:
upotreba GOTO naredbe

izbor programskog jezika

stil uvlaenja

korienje begin - end blokova, kao i korienje zagrada

izbor tekst editora

77

stil komentarisanja

objektno-orjentisani dizajn vs strukturni dizajn

korienje globalnih promenljivih

pravila za imenovanje promenljivih

metrika, posebno broj linija koda dnevno

Ovo su neka od pitanja koja su u principu individualne prirode, i

pripadaju linom programerovom stilu, tako da u njih ne treba
previe zadirati. Ako ipak, kao menader, hoete da imate kontrolu
u bilo kojoj od gore navedenih pitanja vodite rauna o sledeem:
budite svesni da ste na "osetljivom" podruju: Pokuajte da
ispitate programerov stav pre nego to krenete u raspravu o
bilo kom od ovih pitanja.
koristite samo sugestije i predloge: Izbegavajte postavljanje
strogih pravila i krutih standarda.
ta ako programer ve ima razvijene svoje standarde? I
ranije smo spomenuli da su detalji nekog specifinog standarda
manje vani od same injenice da standard postoji. Nemojte
nametati programeru nove standarde ako on ve ima razvijen
svoj, ali insistirajte na standardizaciji onoga to vam je od
izuzetne vanosti.
f) Fiziko okruenje: Evo jednog zanimljivog primera koji e nam
posluiti kao uvod:
Otiite na selo. Pronaite farmu. Pronaite farmera. Pitajte ga
koliko para farmer troi na opremu za svakog svog radnika. ovek
e pogledati ambar, videe par traktora, kombajn i ponosno izjaviti
da svaki zaposleni raspolae opremom vrednom 100,000.00
dolara.
Vratite se u grad. Pronaite neku programersku firmu. Pronaite
menadera. Pitajte ga isto kao i farmera. Menader e baciti
pogled na kancelariju, pogledati radni sto, stolicu, kompjuter,
nekoliko knjiga i CD-ova i ponosno rei da je to manje od
25,000.00 dolara po zaposlenom.
Samo fiziko okruenje ima veliki uticaj na produktivnost. Po
jednom istraivanju sprovedenom nad 166 programera iz 35
organizacija o kvalitetu njihovog fizikog okruenja dolo se do
rezultata prikazanih u tabeli 3:
faktor okruenja
kancelarijski prostor
prihvatljivo miran radni
prostor
prihvatljivo privatan radni
prostor
mogunost iskljuivanja
tona telefona
mogunost preusmeravanja
poziva

prvih 25%
78 m2

poslednjih 25%
46 m2

57% da

29% da

62% da

19% da

52% da

10% da

76% da

19% da

78

esti nepotrebni prekidi rada

radni prostor koji
programera ini
zadovoljnim

38% da

76% da

57% da

29% da

Tabela 3. Uticaj fizikog okruenja na produktivnost programera

Iz tabele je uoljiva velika korelacija izmeu produktivnosti

programera i samog kvaliteta radnog prostora tj. fizikog
okruenja. Programeri koji se nalaze meu prvih 25% su 2.6 puta
produktivniji od poslednjih 25%. Da zakljuimo poboljanje i
unapreenje fizikog okruenja moe vam poveati produktivnost
najmanje 100%.

5.6. Kontroliite svog menadera

U softverskom razvoju gotovo da je pravilo da imate
menadera koji nije tehniki potkovan. Najei izuzetak ovog pravila
je da je menader struno lice, ali za tehnologiju staru 10 i vie
godina. Dakle, pravi tehniki kompetentni menaderi predstavljaju
pravi raritet i ako sluajno radite za nekog takvog dajte sve od sebe da
taj posao zadrite.
U suprotnom, a to je najei sluaj, probajte da ga kontroliete.
Kako kontrolisati svog menadera? Trik je da stvari koje treba uraditi,
ih menader naravno ne razume, "proturimo" menaderu na takav
nain da on i dalje misli da upravlja. Evo nekih smernica koje moete
koristiti prilikom prilaza ovom problemu:
insistirajte na kvalitetu i ispravnosti svog posla, ne dozvolite
da radite pogrene stvari samo zato to je to menader rekao

pretvarajte se da radite onako kako menader eli, a tajno

odradite posao na pravi nain

podmetnite menaderu spisak ideja ta i kako bi trebalo uraditi,

pa saekajte izvesno vreme da menader "doe" do genijalne
ideje (vae ideje) i naredi da je realizujete

pokuajte da "u letu" poduite menadera kako da uradi posao

na pravi nain

ako nita od ovoga ne moete da uradite pronaite drugi posao

najbolje, dugorono reenje je naravno nauiti menadera

onome to ne zna. To je naravno teak zadatak, ali vredi
pokuati.

REZIME

Kada se pravilno primeni, upravljanje konfiguracijom

softverskih projekata olakava programerski posao.

Koristite metriku, pomoi e da precizno realizujete plan,

kontrolite kvalitet i poboljate razvojni proces projekta koji
radite.
79

I programeri i menaderi su ljudi, a kao i svi drugi vole da se

sa njima paljivo postupa.

Prilikom upravljanja razvojem softvera precizna procena

nekog projekta je veliki izazov. Potrebno je probati nekoliko
razliitih alternativa, prouiti razlike u rezultatima procene i
shvatiti bolje projekat, pa e i sam projekat e biti bolje
uraen.

80

6.0. ZAKLJUAK
Poznavanjem osnova programiranja i sintakse bilo kog
programskog jezika pisanje programa se u optem sluaju ne razlikuje
od obrade teksta u nekom od tekst procesora. Dokument kreiran tekst
procesorom moe biti kvalitetno i efikasno formatiran ili ne, u
zavisnosti od toga ko ga je kreirao. Isto vai i za programe.
U prvom delu ovog rada date su smernice i uputstva koje nam
pomau da napisan kod bude pregledan, itljiv, lak za odravanje.
Postoji vie razliitih tehnika i stilova formatiranja pojedinanih
naredbi, kontrolnih struktura, modula, rutina. Vizuelno efikasno
formatiranje se moe postii na vie naina, a cilj je da se pobolja
itljivost samog koda. Veoma je vano da kada se jednom odluimo
za odreeni stil formatiranja, taj stil dosledno primenjujemo do kraja
napisanog programa. Precizno i dosledno moramo prikazati logiku
strukturu koda (uglavnom se koriste praznine ili uvlaenja pojedinih
redova). Tako e struktura koda biti laka za pregledanje i kasnije
odravanje.
Pored samog formatiranja, programska dokumentacija je
takoe vaan aspekt kvalitetnog softverskog proizvoda. 2/3 svih
napora na velikim softverskim projektima odlazi na kreiranje
dokumentacije. Dokumentacija se sastoji od informacija unutar i izvan
listinga samog koda. Samim tim dobar programerski stil je sastavni
deo unutranje dokumentacije. Odabiranjem dobrih imena
promenljivih, rutina, zatim korienje imenovanih konstanti, jasna
struktura podataka kao i dobra programska struktura ine sastavni deo
unutranje dokumentacije.
Komentarisanje i tehnike komentarisanja su takoe veoma
vane kako za sam izgled koda tako i kao programska dokumentacija.
Preporuka je da koristimo sumirajue komentare (komentari koji
objanjavaju vie linija koda) kao i komentare koji izraavaju nameru
koda (oni ne objanjavaju ZATO nego KAKO). Komentari na kraju
linije ili endine komentari su korisni prilikom deklaracije podataka,
kao i za komentare za beleke o odravanju.
Organizovanje itavog procesa oko razvoja, testiranja i
odravanja programa, kao i kreiranjem odgovarajuih alatki za
podrku itavom tom procesu, bavi posebna disciplina raunarskih
nauka: softversko inenjerstvo (eng. software engineering).
Drugi deo rada je blii softverskom inenjerstvu. Moderni
programski alati smanjuju koliinu vremena potrebnu za konstruisanje
softverskih projekata i poveavaju produktivnost i preko 50%. Alati
dizajna koji su trenutno u opticaju su uglavnom grafiki alati koji
kreiraju dijagrame dizajna i esto su uklopljeni u CASE alat sa irim
funkcijama. Alati izvornog koda (editori, brauzeri...) su povezani sa
editovanjem izvornog koda. Takoe, na tritu je dostupan i irok
spektar alata za rad sa izvrnim kodom. Vano je rei da veinu ovih
programskih alata moemo i sami kreirati.
Upravljanje softverskim projektima i izradom softvera je
krajem dvadesetog veka postalo teak zadatak. Tehnike poveanja
81

efikasnosti programiranja nastaju kao rezultat viegodinje prakse.

Programiranje u paru, zahtevanje potpisa odgovornog lica na kraju
listinga programa, nagraivanje uspenih projekata, kao i pravljenje
bacup-plana i njegova periodina primena samo su neke od njih koje
su opisane u ovom radu. Metrika tj. bilo koja jedinica mere vezana za
razvoj softvera takoe predstavlja vaan aspekt upravljanja
softverskim projektima. Neke od metrika koje su se vremenom
pokazale kao korisne su broj linija koda, broj defekata na hiljadu linija
koda, broj globalnih promenljivih, broj radnih sati protrebnih za
realizaciju koda. Sve ove metrike moemo prikupiti uz pomo
softverskih alata koji su na raspolaganju. Vano je da ne koristimo
metriku bez razloga, ve da prvo definiemo ciljeve, odredimo pitanja
na koja treba dati odgovore da bi postigli ciljeve i na kraju iskoristiti
metriku da bi doli do odgovora.
Tehnike i stilovi programiranja navedeni u ovom radu
predstavljaju smernice koje pomau pisanju kvalitetnih, itljivih i
programa lakih za odravanje. Kao takvi korisni su svima koji se bave
pisanjem programa, nezavisno od programskog jezika koji koriste.
Poetnicima pomau da odmah usvoje neki od navedenih stilova i
tehnika, dok iskusniji programeri mogu pronai savet koji e
unaprediti stil koji ve koriste. Vano je napomenuti da jedino
dosledna primena usvojenog stila i tehnika dovodi do eljenog
rezultata.
Poglavlja koja govore o programskim alatima koja poveavaju
efikasnost programiranja, kao i upravljanje softverskim projektima bi
mogla biti detaljnije obraena i u tom smeru treba traiti poboljanje
ovog rada u budunosti.

82

LITERATURA
[1]

Steve McConnell, Code Complete, Microsoft Press 1 edition

(May 14, 1993), 896 pages

[2]

Zoran Budimac, Mirjana Ivanovi, ura Pauni, Programski

jezik Modula 2, Institut za matematiku PMF Novi Sad 1996,
349

[3]

Zoran Budimac, Mirjana Ivanovi, Zoran Putnik, Duan Toi,

Lisp kroz primere, Institut za matematiku PMF Novi Sad 1991,
253

[4]

Nenad Markovi, Predrag Stanimirovi, Programiranje i

programski jezici sa zbirkom zadataka, IDP Nauna knjiga
Beograd 1990, 265

83

Kratka biografija
Fotografija

kandidata

Duan Vajagi je roen 23.09.1970. godine u Bakoj Palanci.

Odrastao je u Bakoj Palanci, gde je i zavrio osnovnu kolu Veselin
Maslea, 1985 godine sa odlinim uspehom. Gimnaziju Jovan
Jovanovi Zmaj u Novom Sadu zavrava 1989. godine takoe sa
odlinim uspehom. Prirodno matematiki fakultet u Novom Sadu,
smer Diplomirani Informatiar upisuje 1991. godine. Po apsolviranju,
1996. godine zapoljava se u Srednjoj strunoj koli dr Radivoj
Uvali u Bakoj Palanci na mestu profesora Poslovne informatike i
Raunarstva i informatike. Fakultet zavrava 2007 godine.

Novi Sad, datum

_________________________
(Duan Vajagi)

84

UNIVERZITET U NOVOM SADU

PRIRODNO - MATEMATIKI FAKULTET
KLJUNA DOKUMENTACIJSKA INFORMACIJA
Redni broj:
RBR
Identifikacioni broj:
IBR
Tip dokumentacije:
TD
Tip zapisa:
TZ
Vrsta rada:
VR
Autor:
AU
Mentor:
MN
Naslov rada:
NR
Jezik publikacije:
JP
Jezik izvoda:
JI
Zemlja publikovanja:
ZP
Ue geografsko podruje:
UGP
Godina:
GO
Izdava:
IZ
Mesto i adresa:
MA
Fiziki opis rada:

Monografska dokumentacija
Tekstualni tampani materijal
Diplomski rad
Duan Vajagi
dr. Mirjana Ivanovi

Stilovi programiranja i
samodokumentujui kod
srpski
srpski / engleski
Srbija
Vojvodina
2007

autorski reprint
Novi Sad, Trg Dositeja Obradovia 4
6/88/0/5/60/0/0

(broj poglavlja/strana/lit. citata/tabela/slika/grafika/priloga)

85

FO
Nauna oblast:
NO
Nauna disciplina:
ND
Kljune rei:
PO
UDK
uva se:
U
Vana napomena:
VN
Izvod:

Raunarske nauke
Obrada teksta, programiranje
Formatiranje koda, stilovi
formatiranja, softeverski projekat

U ovom radu se opisuju stilovi

formatiranja koda nezavisno od
programskog jezika koji se koristi.
Cilj je da korienjem uputstava i
preporuka datih u ovom radu
programeri poetnici, ali i oni
iskusniji, usvoje neka od osnovnih
pravila zapisivanja izvornog koda
programa. Korienje programskih
alata u tu svrhu, kao i upravljanje
konstrukcijom softverskih projekata
takoe zauzima znaajno mestu u
ovom radu.

IZ
Datum prihvatanja teme
NN vea
DP
Datum odbrane:
DO
lanovi komisije:
KO
Predsednik:
lan:
lan:

jul 2007

dr. Mirjana Ivanovi, redovni profesor,

Prirodno-matematiki fakultet, Novi Sad
dr. Zoran Budimac, redovni profesor,
Prirodno-matematiki fakultet, Novi Sad
dr. Dragan Maulovi, vanredni
profesor, Prirodno-matematiki fakultet,
Novi Sad

86

UNIVERSITY OF NOVI SAD

FACULTY OF SCIENCE
KEYWORDS DOCUMENTATION
Accession number:
ANO
Identification umber:
INO
Document type:
DT
Type of record:
TR
Contents Code:
CC
Author:
AU
Mentor:
MN
Title:

Monograph documentation
Textual printed material
Graduation thesis
Duan Vajagi
dr. Mirjana Ivanovi
Programming style and
selfdocumenting code

TI
Language of text:
Serbian
LT
Language of abstract:
Serbian/English
LA
Country of publication: Serbia
CP
Locality of publication: Vojvodina
LP
Publication year:
2007
PY
Publisher:
Author's reprint
PU
Publ. place:
Novi Sad Trg D. Obrdovia 4
PP
Physical description:
6/88/0/5/60/0/0
(no.
chapters/pages/bib.refs/tables/figures/graphs/appendices)
PD

87

Scientific field:
SF
Scientific discipline:
Key words:

Computer Science
Text Processing, Programming
Code Formating, Style Formating,
software project

UC:
Holding data:
HD
Note:
N
Abstract:
AB
Accepted by the Scientific Board on: July 2007
Defended:
DE
Thesis defend board:
(Degree/first and last name/title/faculty)
President:
dr. Mirjana Ivanovi, full professor,
Faculty of Science, Novi Sad
Member:
dr. Zoran Budimac, full professor,
Faculty of Science, Novi Sad
Member:
dr. Dragan Maulovi, associate
professor, Faculty of Science, Novi Sad

88