Greeli frecvente n predarea programrii n liceu

M. Freniu
(Didactica Matematicii, Turda, 14 mai 2005)
1. Introducere
De peste 25 de ani predau studenilor din anul nti primul curs de programare. La
primele ore de seminar, n orele de laborator i apoi la examenele de sfrit de semestru am
observat deprinderile greite cu care vin unii absolveni de liceu. Am avut destule exemple
de elevi (considerai) foarte buni n liceu care nu au reuit s promoveze examenul din
prima ncercare.
Analiznd ns manualele colare ne putem da seama c nu numai elevii sunt
vinovai pentru deprinderile greite cu care vin din liceu. Aceste manuale sunt pline de
greeli, sunt scrise uneori de profesori care nu tiu ce este programarea, iar programa
colar este cam aceeai cu cea conceput cu peste 30 de ani n urm. In aceti ani situaia sa schimbat radical, concluzia c simplitatea i claritatea sunt atribute foarte importante n
programare este general acceptat, iar necesitatea respectrii unor reguli este consecina
ultimelor decenii de programare.
Personal mi-am pus de mai multe ori ntrebarea dac e bine ca elevii s nvee
programarea nc din prima clasa de liceu. Intrebarea rmne, pentru c deprinderile
greite se nltur greu, de cele mai multe ori nsoesc persoana n cauz n ntreaga sa
activitate. Cred c e bine ca elevii s tie programa, dar este necesar nlturarea multor
neajunsuri din programa colar, din manualele colare i din activitatea la clas.
Vom ncerca n cele ce urmeaz s prezentm acele aspecte pe care le considerm
negative n procesul de nvare a programrii de ctre elevi. Aceste aspecte vor fi i titlurile
seciunilor care urmeaz. Ele sunt:
- rolul proiectrii n programare;
- importanta conceptului de subalgoritm;
- simplitate versus complexitate;
- greeli grave n manualele colare rsfoite.
2. Rolul proiectrii n programare
Una din cele mai rele deprinderi cu care vin elevii din liceu este fuga la calculator
pentru a scrie programul pentru rezolvarea problemei primite. Nu-i pun ntrebarea dac
cunosc bine i tiu rezolva problema, dac metoda aleas este cea mai potrivit, dac
algoritmul e corect. De fapt nu au algoritm ci scriu direct n limbajul de programare
instruciuni care, sper ei, vor forma programul dorit. Puin atenie se d n liceu
proiectrii programelor.

Se tie c majoritatea programelor realizate azi pe plan mondial conin erori la

predarea lor la beneficiar [Bro87, Fre05], iar majoritatea erorilor provin dintr-o proiectare
greit. Iar una dintre regulile importante de programare spune [Led70, Ker74, Gri90]:
Gndete mai nti, programeaz pe urm
Ea presupune definirea complet a problemei, deci precizarea datelor de intrare i a
rezultatelor dorite precum i a condiiilor pe care trebuie s le satisfac aceste date, apoi
alegerea metodei de rezolvare i scrierea algoritmului corespunztor i abia apoi traducerea
algoritmului n limbajul de programare, adic programarea propriu-zis. Pentru c altfel ne
vom ntlni cu o alt lege a lui Murphy: The sooner you start coding your program (instead
of thinking) the longer it will take to finish it [Led70].
Considerm c un mai mare accent trebuie pus pe proiectarea algoritmilor,
independent de limbajul de programare folosit, pe scrierea lor pe hrtie nainte de a atinge
calculatorul. Pentru studenii anului nti condiia de intrare la orele de laborator este
redactarea n caietul de laborator a algoritmului pe care-l vor folosi n lucrarea respectiv.
Evident, pentru scrierea algoritmilor se va folosi un pseudolimbaj special dedicat
descrierii algoritmilor. La nceputurile programrii se foloseau n acest scop schemele logice,
utile pentru nceptori, dar neadecvate programrii structurate i conceperii unor
programme reale, mult mai complexe dect exemplele didactice simple. El nu este
recunoscut de calculator, are propoziii asemntoare celor ale limbajului natural i trebuie
s poat reda structurile de calcul necesare rezolvrii problemelor. E cunoscut sub numele
de Pseudocod i exist mai multe variante, care pot diferi de la programator la programator.
Oricare ar fi varianta aleas ea trebuie s conin un minim de propoziii care corespund
structurilor de calcul strict necesare i care s respecte metodologia programrii.
n [Pt98] exist un limbaj Pseudocod gndit de autor, dar care nu respect cerinele
de mai sus. Si alte manuale au un astfel de Pseudocod. Limbajul Pseudocod nu e al meu sau
al unui autor oarecare. El este consecina unei evoluii istorice, a unei experiene i a unor
rezultate obinute n aceti ani. Manulalul menionat chiar vorbete de programarea
structurat i de teorema Bohm-Jacopini conform creia tim c trei structuri de calcul sunt
suficiente pentru a scrie un algoritm compus numai din aceste structuri i echivalent cu un
algoritm dat. Limbajul Pseudocod este consecina acestei evoluii i trebuie s respecte
regulile de programare general recunoscute [Gri90, Led70, Ker74, Fre05].
Subliniez de la nceput c Pseudocodul este un limbaj ct mai simplu, apropiat
limbajului natural, dar fr ambiguiti i expresii inutile. Voi sublinia importana claritii
i simplitii n seciunea 4. Un algoritm trebuie s fie ct mai clar i concis, fr litere i
cuvinte n plus. Regulile programrii structurate cer folosirea celor trei structuri de calcul
deja menionate, dar i prezena structurii n textul scris, pentru asigurarea claritii.
Trebuie "s sar n ochi" nceputul i sfritul oricrei propoziii, prin scriere s asigurm
aceast claritate.
De aceea, consider c un minim de propoziii care definesc cel mai redus Pseudocod,
trebuie s conin urmtoarele propoziii:
CITESTE listaDeVariabile
TIPARESTE listaDeVariabileSiMesaje
[FIE] variabila := expresie
DACA conditie ATUNCI s1 [ ALTFEL s2] SFDACA
CATTIMP conditie EXECUTA s1 SFCAT
SUBALGORITMUL nume(l.p.f.) ESTE: s1 SF-nume
CHEAMA nume(l.p.a.)
2

unde l.p.f. reprezint lista parametrilor formali iar l.p.a. reprezint lista parametrilor
actuali. Ultimele dou propoziii sunt strns legate de folosirea subalgoritmilor, care va fi
discutat n seciunea 3.
Aici am scris cuvintele fixe cu litere mari, dar n textul algoritmilor ar trebui s
scriem dup regulile limbii romne, prima liter are rolul de a sublinia nceputul unei
propoziii iar punctul de a marca sfritul ei. Doar c n programare punctul are un alt rol,
motiv pentru care trebuie evitat folosirea lui n alte scopuri, iar pentru marcarea sfritului
propoziiilor exist alte convenii. Astfel, cuvntul Cttimp (unul singur, nu dou cuvinte)
este i numele structurii repetitive, special ales n acest scop, iar sfct e un cuvnt ce
marcheaz sfritul acestei propoziii i nlocuiete punctul din limbajul natural. Nu este
nevoie de nici un alt cuvnt pentru a marca nceputul secvenei s1, secven care ncepe dup
cuvntul execut. Este nevoie de un astfel de marcaj de sfrit ntruct secvena s1 este o
secven de oricte propoziii Pseudocod, separate prin caracterul ;. Un rol asemntor l
are cuvntul sfdac, care marcheaz sfritul secvenei s2 (respectiv s1 n cazul n care
lipsete alternativa ALTFEL), secvene ce pot conine oricte propoziii.
Evident, limbajul Pseudocod poate conine i alte propoziii (n mod deosebit
menionez propoziiile REPET ... , respectiv PENTRU ...).
Unele manuale folosesc un Pseudocod cu cuvinte din limba englez [Nic01].
Considerm nepotrivit o astfel de alegere pentru c proiectarea trebuie fcut independent
de limbajul de programare. Cuvintele respective apropie Pseudocodul ales de limbajul de
programare, n loc s accentueze aceast independen.
Un rol important n programare l are specificarea problemei ce trebuie rezolvat.
Specificarea este prima etap, ce precede proiectarea. Din pcate ea lipsete din aproape
toate manualele colare, Excepie face [Ran03]. Specificarea unei probleme P, deci i a
algoritmului A corespunztor, trebuie s precizeze ce se cunoate n problem i ce se dorete
s se obin. De asemenea, trebuie s reflecte tot ce se tie despre aceste elemente. Ea poate fi
fcut prin dou propoziii foarte simple, sub forma:
DATE X
REZULTATE Z
unde X este lista variabilelor de intrare (care marcheaz datele cunoscute n problem), iar
Z este lista variabilelor care marcheaz rezultatele dorite (variabilele de ieire). In plus
trebuie spus tot ce se tie despre variabilele de intrare sub forma unei precondiii satisfcute
de aceste variabile i ce legtur exist ntre rezultate i variabilele de intrare, sub forma
unei postcondiii. Precondiia i postcondiia se vor scrie ct mai simplu, folosind notaiile
cunoscute n matematic i propoziii n limba romn. Scrierea specificaiei asigur
cunoaterea problemei i nu este banal. Cernd studenilor la nceputul anului nti s scrie
specificaia problemei rezolvrii ecuaiei de gradul doi rareori am obinut un rspuns corect,
Absolvenii de liceu nu tiu exact ce rezultate se cer n aceast problem (ei spun c
rdcinile x1 i x2 sunt rezultatele, omind o a treia variabil care reine dac au existat
rdcini reale sau nu). La o problem mai dificil scrierea specificaiei este o activitate
serioas.
Ca exemplu la cele de mai sus vom scrie un subalgoritm pentru ridicarea la putere
prin nmuliri repetate. Specificarea acestuia este :
Date a,b ;
Precondiia : a,bN, a0
Rezultate p ; Postcondiia : p = ab

Pentru rezolvare pornim de la condiia

I ::= p*uv =ab
pe care o vom menine adevrat pe timpul execuiei subalgoritmului. Iniial ea devine
adevrat dac p=1, u=a i v=b. Execuia trebuie s se termine cnd v=0 deci I devine p = a b.
Subalgoritmul este dat n continuare i el folosete atribuirea multipl, (x,y) :=(f,g)
nsemnnd c se calculeaz expresiile f i g i simultan variabilele x i y primesc valorile
celor dou expresii.
Subalgoritmul Putere(a,b,p) este : { p := ab }
Fie (p,u,v) := (1,a,b) ;
{ p*uv =ab este adevrat}
Cttimp v>0 execut
Dac v mod 2 = 0
atunci (u,v) := (u*u, v div 2) {cazul v e par}
altfel (p,v) := (p*u, v-1)
{cazul v e impar}
sfdac
{ pe ambele ramuri I rmne adevrat}
sfct
{aici v este 0 deci : p = ab}
sf-Putere

3. Importana conceptului de subalgoritm

Dei folosirea subalgoritmilor/subprogramelor este extrem de important n
programare, prezena subalgoritmilor n procesul de nvmnt liceal las foarte mult de
dorit. Absolvenii claselor de informatic vin la facultate fr deprinderi de a folosi
subalgoritmi n programare i accept foarte greu s-i schimbe stilul de programare
dobndit n liceu. Am prezentat acest aspect n dou articole tiprite n Gazeta de
Informatic [Fre00, Fre02], n care artam greelile frecvente fcute de elevi la examenul de
admitere n facultate.
Din pcate nici editorul acestei Gazete nu cunoate acest concept, ntruct i-a permis
s schimbe n titlul articolului cuvntul subalgoritm n algoritm i s intervin n textul
articolului (modificnd Pseudocodul folosit !).
Cnd vorbim de un algoritm ne gndim i la o problem pe care o rezolv acest
algoritm. Iar cnd definim un subalgoritm trebuie s explicm cele dou pri ale acestui
cuvnt: sub i algoritm. n primul rnd el este un algoritm pentru rezolvarea unei probleme
P. Numai c aceast problem este o parte dintr-o problem mai complex C. Iar pentru
algoritmul de rezolvare a problemei C, algoritmul de rezolvare a problemei P este un
subalgoritm. De aici provine i diferena dintre algoritm i subalgoritm. n orice problem
exist date cunoscute i rezultate dorite. Algoritmul problemei C trebuie s citeasc datele
cunoscute n problema C i trebuie s tipreasc rezultatele obinute. Pentru subproblema P
datele presupuse cunoscute sunt de multe ori rezultate intermediare obinute de algoritmul
problemei C i nu sunt cunoscute de ctre programator, deci nu pot fi citite! De asemenea,
rezultatele obinute de subalgoritmul problemei P nu sunt rezultatele problemei C care ne
intereseaz, ele pot fi rezultate intermediare pentru continuarea rezolvrii problemei C.
Deci nu trebuie tiprite. De aici rezult i semnificaia listei parametrilor formali din
definiia unui subalgoritm i, corespunztor, a listei parametrilor actuali. Este obligatoriu ca
4

lista parametrilor formali s conin variabilele care marcheaz datele presupuse cunoscute
n subproblem i variabilele care marcheaz rezultatele obinute, deci toate variabilele care
intervin n specificarea subalgoritmului. Este sarcina algoritmului care apeleaz
subalgoritmul s decid ce face cu aceste date i ce rezultate tiprete.
La examenele de admitere aproape toi candidaii care au tiut scrie subalgoritmii
cerui au citit i tiprit n subalgoritmi i aproape toi au avut subalgoritmi fr list de
parametri formali, variabilele globale fiind singura comunicaie ntre modulele programului.
Este una din deprinderile grave cu care vin marea majoritate a elevilor de liceu.
Cele scrise mai sus provin i din scopul pentru care s-a inventat conceptul de
subalgoritm. Nu este aici spaiul suficient s artm importana subalgoritmilor n
programare. Ne limitm s punctm doar cteva avantaje:
Reutilizabilitate. Subalgoritmii se pot refolosi ori de cte ori apare subproblema
respectiv n alte probleme;
- Mrirea productivitii n programare i prin refolosirea subalgoritmilor existeni i prin
- Simplificarea activitii de programare. Fiind doar o parte din problema de rezolvat este
mult mai uor i mai sigur s proiectm subalgoritmii respectivi;
- Reducerea complexitii programului. Activitatea de programare este o activitate
intelectual dificil [Bro87], cu un efort deosebit necesar pentru testarea programelor i
depanarea lor. Descompunerea problemei complexe n pri mai mici, ct mai simple,
uureaz rezolvarea ei, permite conceperea unui algoritm verificabil, compus din
subalgoritmi ct mai simpli [Flo67, Fre01a, Gri81, Sch90]. Unele tratate sugereaz o
margine superioar pentru lungimea unui subalgoritm, ca fiind 50 de propoziii. Nu
exist o explicaie pentru aceast limit, dar exist o demonstraie pentru ca nici un
subalgoritm s nu conin mai mult de 20 de condiii (foarte multe) altfel el nu mai poate
fi testat de om!!! Se recomand ca n orice subalgoritm s existe ct mai puine condiii,
zece sugernd c testarea subalgoritmului poate cere 2 10 execuii! Cum s-ar testa un
algoritm care nu apeleaz subalgoritmi i conine 50 de condiii? Sunt necesare pn la
250 execuii!
- Apare posibilitatea ca n rezolvarea unei probleme s lucreze mai muli programatori,
fiecare dintre ei scriind cteva proceduri. Fr subalgoritmi programarea modular nu
exist!

4. Simplitate versus complexitate

Chiar i pentru autorul unui program, nelegerea acestui program dup un an sau
doar cteva luni de la scriere poate fi dificil. Intruct reutilizarea sau ntreinerea cer
nelegerea unor proceduri scrise anterior este important s uurm aceast nelegere prin
orice mijloace. Iar azi, cnd se concep programe uriae, realizate de echipe compuse din zeci
de programatori, deci multe persoane trebuie s descifreze texte scrise de alii, cnd echipele
de inspectare [Fre04] fac zilnic aa ceva, claritatea textelor surs este foarte important.

De aceea, prin orice mijloace, trebuie s asigurm aceast claritate. Iar una din aceste
posibiliti este folosirea comentariilor n textul surs. Din pcate puine manuale fac
acest lucru. Chiar i manualele bune conin programe fr nici un comentariu [Nic01]. E
uor de neles c nu e timp s scriem comentarii pe tabl, dar nu e admisibil lipsa acestora
ntr-un manual, la care profesorul face apel ca model i, cel puin, amintete de utilitatea
comentariilor.
Claritatea textului i simplitatea subprogramelor uureaz nelegerea lor i sunt
atribute de calitate importante. Inspectarea, testarea, depanarea, reutilizarea, sau
ntreinerea cer unor persoane s neleag texte surs scrise de ali programatori. Aceast
nelegere depinde n primul rnd de modul n care a fost proiectat programul, apoi de
claritatea textului i de simplitatea subalgoritmilor folosii. Att depanarea, ct i
ntreinerea sunt activiti foarte costisitoare ca pre, dar i ca efort intelectual. Artificiile
fcute atunci cnd nu sunt necesare ngreuneaz fr rost nelegerea acestor programe, fac
dificil modificarea/adaptarea unor proceduri la alte structuri de date, sau adugarea unor
funcii noi.
Relaia dintre complexitate i simplitate n programare este abordat n foarte multe
articole. Menionez doar cteva [Cap03, McG04, Ven03, XXX05]. Celebrul Meyer spunea
[Ven03] :
"The single biggest enemy of reliability and perhaps of software quality in general is
complexity."
Trebuie subliniat de la nceput c exist dou nelesuri ale cuvntului complexitate, dou
tipuri de complexitate. E complexitatea calculului fcut de un algoritm, complexitate
prezent n manualele colare i complexitatea structural, redat de textul algoritmului,
care uureaz sau ngreuneaz nelegerea acestui text. Cutnd s micorm complexitatea
calculului facem artificii i mrim complexitatea structural. Si de multe ori complexitatea
calculului este mai puin important dect complexitatea structural.
Fiindc orice program serios este folosit de mai multe persoane i trebuie citit i
neles de aceste persoane. Dar nu am ntlnit n nici un manual meniuni despre simplitatea
textului. Dimpotriv, se gsesc destule exemple de algoritmi complicai, de tendina de a
complica lucrurile i chiar conceptul de stil n programare e incorect definit [Pt98, pg.13].

5. Greeli de nlturat din manualele colare rsfoite

M voi referi i la erori n unele manuale colare. Nu pentru c aceste manuale ar fi
exemple de manuale greite. In orice carte exist greeli i cred c n orice manual se gsesc
greeli de tot felul (tehnoredactare, exprimri greite etc). Si nu am rsfoit dect cteva
dintre multele manuale existente.
Nu m voi referi la erori minore, ci la definiii i concepte greite, la exemple
nepotrivite, la nclcarea unor principii general acceptate n ingineria programrii. Sunt
convins c unele concepte i reguli nu pot fi explicate elevilor, dar profesorii trebuie s le
cunoasc i s le respecte implicit.
Astfel, n [Mat00] se spune "Scopul organizrii n subprograme este acela de a apela
un subprogram de mai multe ori" !? In consecin, dac nu e nevoie de cel puin dou
apeluri nu trebuie s folosim subprograme. Oare autorul tie ce este programarea top-down,
reutilizarea, care sunt atributele de calitate ale unui program? Sigur, ele nu figureaz n
programa colar, dar absolvenii unei faculti trebuie s le tie i s le respecte. i cu att

mai mult ele trebuie respectate de autorii unor manuale. De altfel, eu consider mai vinovai
de aceste erori pe referenii manualelor, care i-au dat girul lor unor astfel de texte greite. i
cred c n-ar fi ru ca aceti refereni, pentru a nu mai semna referate fr a verifica
manuscrisele, s fie penalizai material pentru greelile grave ntlnite n manualele colare
girate de ei.
i mai puin se spune despre parametrii unui subprogram: Exist ns i
subprograme fr parametri. Dar cine trebuie s fie parametrii nu se explic nicieri.
n aproape toate manualele folosirea variabilelor globale este pe prim plan! Iar
variabilele globale trebuie evitate n programare [Fre93, Fre00c, Fre01a, Gri81].
Nu se cunoate bine conceptul de subalgoritm de toi cei ce citesc date i tipresc
rezultate n interiorul subalgoritmilor care nu au acest rol. Cine cunoate rolul
subalgoritmilor va respecta regula
"Nu citi i nu tipri ntr-un subalgoritm, dect dac specificaia sa o cere"!
De exemplu, in [Mat00, pag. 23] subprogramul calculMedia conine instruciunea
writeln(' M=', M:8:2)
In plus, procedura menionat nu are parametri formali. In tot manualul nu se explic cine
trebuie s fie parametrii formali. Se insist pe prezentarea limbajului Pascal, pe faptul c
parametrii formali pot fi parametri valoare sau parametri referin, dar nu e clar ce trebuie
s conin lista parametrilor formali.
Astfel, la pagina 30 se scrie o alt procedur calcul_media(a,b:real) care nu are
parametru formal pentru rezultat. Care e specificarea acestei proceduri, n ce scop se va
folosi?
Accentul e pe limbaj nu pe activitatea de programare. De aici deprinderile greite,
chiar manualul punnd un mare accent pe variabilele globale. Credem c mai bine fr ele
dect cu asemenea deprinderi. Viitorii programatori trebuie s nvee regulile de
programare corecte i abia dup aceea excepiile posibile.
Consider nepotrivit introducerea conceptului "programarea structurat" n primele
ore din clasa a noua. In plus, e dificil a defini ce este programarea structurat. Iar definiia
din [Pt98] care spune c programarea "devine o art, atunci cnd se folosesc cele trei
elemente de structurare i se numete programare structurat" este departe de a fi o
definiie a acestui concept. Elevii pot nva foarte bine programarea structurat fr s tie
c se numete astfel dac cei ce predau o cunosc, dar nu neleg nimic atunci cnd acest
concept nu este nteles de profesor. Imi amintesc c n 1977 am citit un material intern ICI n
care se ddeau peste 70 de definiii-caracterizri ale programrii structurate [Teo76].
Definiia ar trebui s reuneasc cele mai importante caracteristici i aici aleg un minim fr
de care nu putem vorbi de programare structurat [Dah72, Fre94, Vd78]:
- folosirea celor trei structuri de calcul;
- lipsa instruciunii GOTO;
- prezena structurii n text pentru asigurarea claritii;
- practicarea programrii modulare i top-down, bine cunoscute n momentul n care DahlDijkstra-Hoare [Dah72] au introdus programarea structurat. Deci, nu exist programare
structurat fr folosirea subalgoritmilor.
Dei programarea structurat o presupune, programarea descendent (top-down) nu
e prezent n programa sau manualele colare. Fr a o prezenta, menionm doar c
programarea descendent presupune [Led75]:
- definirea exact a problemei;
- proiectarea iniial independent de calculatorul i limbajul de programare folosite;
7

proiectarea pe nivele (etape). Fiecare etap se obine din precedenta prin rafinarea
unei pri din etapa precedent;
- amnarea detaliilor pentru etapele ulterioare, trzii;
- asigurarea corectitudinii la fiecare etap;
- rafinarea n pai succesivi (a subalgoritmilor).
Nu exist proiectarea programelor scrise n nici unul din manualele referite! Dei
Tudor [Tud00] prezint un limbaj Pseudocod, nu folosete acest limbaj n capitolele
urmtoare. Cu ce scop a fost prezentat? Descrie ns metoda (ideea) folosit, fr ca textul
dat s fie un algoritm Pseudocod [Tud00, pg.201, 202], dar folosete exprimarea Algoritmul
este:, iar ceea ce urmeaz nu este un algoritm.
Nici conceptul de variabil nu e suficient de bine explicat. Intruct el contribuie
foarte mult la claritatea textului surs considerm c ar trebui mai mult insistat asupra
acestui concept. In primul rnd c fiecare variabil e folosit ntr-un anumit scop, deci are o
semnificaie a sa. Si, ca regul important n programare, nu trebuie s folosim acelai nume
pentru semnificaii diferite!!! Ca exemplu, n [Tud00, pg.112-3] se cere ctul i restul
mpririi ntregi a dou numere naturale, n1 la n2. Este nevoie de variabile care s
marcheze rezultatul i c este folosit pentru ct, dar nu exist un nou nume pentru
semnificaia rest, folosind n acest scop pe n1, care are deja o alt semnificaie. Aparent e
un lucru banal pentru unii, dar o greeal grav pentru o programare serioas!
Exist i greeli de neatenie, erori corectabile, dar totui prezente. Inc odat spun
c referenii ar trebui penalizai pentru erorile grave, de coninut, i nici un manual nu ar
trebui publicat fr cel puin doi refereni.
Menionez cteva erori gsite n manualele referite, convins c orice carte poate
conine erori inerente, dar nu toate erorile sunt la fel de grave. Conceptele nu trebuie s fie
greit definite!
Astfel, n [Pt98, pg.12] se spune c problema trebuie s fie neleas i de ctre
calculator, apoi calculatorul va trebui s cunoasc metoda de rezolvare. Oare ce nelege
calculatorul?
Tot n [Pt00a, pg.16], n prima lecie despre algoritmi se vorbete despre
complexitate. Elevul nu tie nc scrie algoritmi pentru rezolvarea unei probleme, dar se
consider important s tie ce este complexitatea. E definit? Nici un concept n-ar trebui s
fie folosit nainte de a fi definit!
Ideea de a compara doi algoritmi ntre ei este important, dar conceptul complexitate
e greu de predat elevilor de liceu. Intre doi algoritmi care fac 2n, respectiv 3n operaii pentru
rezolvarea aceleai probleme elevii vor nelege uor c primul este mai bun. Dar numrul
mediu de operaii executate de un algoritm este greu de evaluat pentru marea majoritate a
algoritmilor. Ca exemplu, pentru a calcula numrul mediu de comparaii fcut de algoritmul
Quicksort la nivelul elevilor de clasa a X-a, n [Mat00, pag.203-4] se face apel la cunotine
de Analiz matematic (clasa a XI-a).
In [Mat00, pg.186] se d o funcie care calculeaz maximul dintr-un ir de numere, ca
exemplu de aplicare a metodei Divide et Impera. E un exemplu nepotrivit, algoritmul dat
fiind mai complicat dect algoritmul bazat pe parcurgerea secvenial a celor n numere. Nu
e nevoie s form astfel de exemple n dauna simplitii.
Un exemplu similar este determinarea celui mai mare divizor comun a n numere
[Mat00, pag.208], care foreaz din nou folosirea metodei Divide et Impera. De ce trebuie s
complicm algoritmii ?

6. Concluzii
Am prezentat n paginile anterioare cteva preri personale privind predarea
programrii n liceu. In mai multe articole [Fre84-Fre05] m-am referit la corectitudinea
algoritmilor i la regulile importante ce trebuie respectate pentru asigurarea ei. Aceste
articole se bazeaz pe o vast bibliografie care este folosit indirect i aici, fr a mai fi
rescris. Chiar dac nu pot fi predate elevilor, aceste reguli trebuie cunoscute de profesori !
Sigur, nu poate exista o unanimitate n privina celor prezentate. Iar o schimbare radical nu
se poate produce fr modificri n programa colar i n pregtirea profesorilor care
predau programarea.
In ordinea importanei aceste modificri ar fi :
- o clar definire i folosire a conceptului de subalgoritm ;
- proiectarea algoritmilor naintea scrierii programelor ;
- respectarea unor reguli importante n programare :
. evitarea folosirii variabilelor globale ;
. scrierea indentat pentru asigurarea claritii;
. folosirea comentariilor n autodocumentarea programelor;
. alegerea unui Pseudocod adecvat;
- schimbarea locului subalgoritmilor n programa colar. Subalgoritmul trebuie s se
predea mult mai devreme dect n actuala program.
Cred c nu e greu s se cunoasc ce este reutilizarea i elevii ar trebui s neleag
acest concept. Elevii trebuie s conceap orice algoritm cu gndul la reutilizare, deci s-l
scrie ca un subalgoritm SP apelabil n orice program, iar algoritmul va avea structura
Citete X;
Cheam SP(X,Z)
Tiprete Z
unde X este vectorul de intrare, iar Z este vectorul de ieire. Este de fapt algoritmul necesar
testrii subalgoritmului SP. Dac SP nu e destul de simplu el trebuie obligatoriu descompus
n ali subalgoritmi!
Bibliografie.
[Bro87] Fred Brooks, No Silver Bullet. Essence and Accidents of Software Engineering,
Computer, vol.20(1987), n0.4, p.10-19
[Cap03] Paul Caplan, Complexity is the root of all Evil, Simplicity, 2003, dec.12,
jroller.com/page/paulcaplan/
[Dah72] Dahl O.J., E.W.Dijkstra,and C.A.R.Hoare, Structured programming, Academic
Press, New York, 1972.
[Fre84] Freniu M., On the program correctness, Seminar on Computer Science, preprint
1984, 75-84.
[Fre93] M.Freniu, B.Prv, Programming Proverbs Revisited, Studia Universitatis BabeBolyai, Mathematica, XXXVIII (1993), 3, 49-58.
[Fre94] M.Freniu, B.Prv, Elaborarea Programelor. Metode i Tehnici Moderne, Promedia,
Cluj-Napoca, 1994.
[Fre95] M. Frentiu, Reguli de programare pentru incepatori, in Lucrarile Conferintei
"Informatizarea invatamantului", Balti, 4-7 octombrie 1995, pp. .

[Fre97] M.Freniu, On program correctness and teaching programming, Computer Science

Journal of Moldova, vol.5(1997), no.3, 250-260.
[Fre00a] M.Freniu, On programming style program correctness relation, Studia Univ.
Babe-Bolyai, Seria Informatica, XLV(2000), no.2, 60-66.
[Fre00b] M.Freniu, Conceptul de subalgoritm i importana lui, Gazeta de Informatic,
vol.10(2000), nr.6.
[Fre00c] M.Freniu, I.Lazr, Bazele programrii. Proiectarea algoritmilor, Ed. Univ.PetruMaior, Tg.-Mure, 2000, 184 pagini, ISBN 973-8084-06-7
[Fre01a] M.Frentiu, Verificarea Corectitudinii Programelor, Ed. Univ.Petru-Maior, Tg.Mure, 2001, 116 pagini, ISBN 973-8084-32-6
[Fre01b] M. Freniu,and H.F.Pop, A Study of Licence Examination Results Using Fuzzy
Clustering Techniques, Research Seminar on Computer Science, 2001, pp. 99-106.
[Fre02a] M. Freniu, The Impact of Style on Program Comprehensibility, Proceedings of the
Symposium Zilele Academice Clujene, 2002, pp. 7-12
[Fre00b] M.Freniu, Admitere la UBB 2002, Gazeta de Informatic, vol.12(2002), nr.7.
[Fre02c] M. Freniu, H.F.Pop, A Study of Dependence of Software Attributes using Data
Analysis Techniques, Studia Universitatis Babe-Bolyai, Informatica, 47(2),2002, 5360.
[Fre03] M. Freniu, On programming style, Babes-Bolyai University, Department of
Computer Science, http://www.cs.ubbcluj.ro/ mfrentiu/articole/style.html
[Fre04] M. Freniu, Program Correctness in Software Engineering Education, Proceedings
of the International Conference on Computers and Communications ICCCM4,
pp.154-157, Oradea, 2004, may 27-29.
[Fre05] M. Freniu, Correctness: a very important factor in programming, Studia
Universitatis Babe-Bolyai, Informatica, 50(1),2005, 11-21.
[Gri81] Gries D., The Science of Programming, Springer-Verlag, Berlin, 1981.
[McG04] Gerry McGovern, Achieving greater simplicity involves managing increasing
complexity,
New
Thinking,
2004,
nov.22,
www.gerrymcgovern.com/nt/class/overload.htm
[Ker74] Briam Kernigham & P.J.Plauger, The Elements of Programming Style, McGraw-Hill
Book Company, New York, 1974.
[Led75] Ledgard H.F., Programming Proverbs for Fortran Programers, Hayden Book
Company, Inc., New Jersey, 1975.
[Mat00] Mateescu George Daniel, Pavel Florin Morariu, Otilia Sofron, Informatica cls.IX-a,
Ed. Petrion 2000
[Nic01] Stelian Niculescu, Vasile Butnaru, Marius Vlad, Informatica. Manual pentru clasa a
X-a, Teora, 2001.
[Pt98a] Bogdan Patrut, Manual de Informatica. Algoritmi si limbaje de programare,
Ed.Teora, 1998.
[Pt98b] Bogdan Patrut, Manual de Informatica. Programarea calculatoarelor, Ed.Teora,
1998.
[Ran03] Doina Rancea, Informatica pentru liceu i bacalaureat, Materia de clasa a IX-a,
Editura Donaris, Sibiu, 2003.

10

[Tud00] Tudor Sorin, Informatica. Varianta C++, Manual pentru clasa a IX-a, Editura L&S
Infomat.
[Sch90] Schach S.R., Software Engineering, IRWIN, Boston, 1990.
[Teo76] B.Teodorescu, R.Bercaru, Programare structurat. Suport de studio, ICI, Bucureti,
1976.
[Vd78] I.Vduva, V.Baltac, V.Florescu, I.Floricic, Programare structurat, Ed.Tehnic,
Bucureti, 1978.
[Ven03] The Demand for Software Quality. A Conversation with Bertrand Meyer, Part I
by Bill Venners, October 27, 2003.
[Xxx05] *** Performance and Optimization in the Real World, TopCoder Feature, March
2, 2005, http://www.topcoder.com/
[Wir71] Wirth N., Program development by stepwise refinement, Comm. ACM 14(1971), 4,
221-227.

11