Proiect didactic

Clasa: a XII-a real

Profesor: Ieeanu Ecaterina
Unitatea de nvare: Modele
Tema: Rezolvarea problemelor .Elaborarea algoritmului scrierea

programului testarea programului. analiza si interpretarea rezultatelor.

Tipul leciei: Lecie mixt
Locul de desfurare: - cabinetul de informatic
Durata leciei: 45 min.
SCOPUL LECIEI:
INFORMATIV
- fixarea i consolidarea noiunilor teoretice prin fie de lucru i aplicaii
concrete;
FORMATIV
- formarea deprinderilor de utilizare corect a instrumente de lucru
pentru sistemele informatice;
EDUCATIV
- dezvoltarea atitudinii pozitive fa de instrumentele de lucru n toate
domeniile de activitate;
- stimularea dorinei de o cunoatere ct mai larg;
- exprimarea unui mod de gndire creativ;
NIVELUL INITIAL AL CLASEI:
- elevii i-au nsuit toate noiunile teoretice legate de prelucrarea
datelor ;
- elevii utilizeaz corect noiunile nvate;
COMPETENE GENERALE :
- Organizeaz i prelucreaz informaiei;
COMPETENTE SPECIFICE :
- clasificarea i folosirea tipurilor de date cunoscute;
- identificarea operatorilor i funciilor studiate;
OBIECTIVE OPERATIONALE :
- la sfritul leciei elevii vor fi capabili s defineasc noiunea de
scenariu, s creeze i s manipuleze scenarii, s creeze un sumar al
scenariului creat.

STRATEGIA DIDACTIC:
Principii didactice
- principiul participrii i nvrii active;
- principiul asigurrii progresului gradat al performanei;
- principiul conexiunii inverse(feedback-ului).
Metode de nvmnt
- metode de comunicare oral: conversaia, explicaia;
- metode de aciune: exerciiul, problematizarea;
Procedee de instruire
- itemi de consolidare;
- explicaia (n etapa de asimilare a noilor cunotine);
- aplicaii de consolidare;
Forme de organizare a activitii instructive
- frontal;
- individual;
Forme de dirijare a activitii
- dirijat de profesor sau prin materiale didactice;
Resurse procedurale :
- explicaia, conversaia, exerciiul;
Resurse materiale
:
- reea de calculatoare, aplicaia AeL, manualul, fie de lucru;
BIBLIOGRAFIE :
- " Tehnologia Informaiei i Comunicaiilor" , de Mariana
Miloescu, manual clasa a IX a Ed. Didactic i Pedagogic.
DESFURAREA ACTIVITII
1. Momentul organizatoric
pregtirea leciei
- ntocmirea proiectului didactic;
- pregtirea temei;
- pregtirea setului de ntrebri;
- pregtirea setului de aplicaii ;
organizarea i pregtirea clasei
- verificarea frecvenei elevilor;
- verificarea existenei resurselor materiale;
2. Captarea ateniei clasei
anunarea subiectului pentru tema respectiv;
anunarea obiectivelor urmrite ;
explicarea modului de desfurare a activitii

Durata

Activitatea desfurat de profesor

Activitatea elevilor

Metoda de
nvmnt

2 min

Momentul organizatoric
Se stabilete prezena i se verific dac sunt asigurate condiiile didactico-materiale
utile desfurrii leciei.

Raporteaz absenii.

Conversaia

Evaluare

Reactualizarea cunotinelor dobndite anterior se realizeaz printr-un test n AeL

7 min

Operatorii sunt:
a.
combinaii de cifre i litere cu o ordine bine stabilit;
b.
simboluri sau cuvinte cheie prin care se reprezint operaiile;
c.
definii printr-un nume i o list de parametrii;
2. Stabilii valoarea de adevr a afirmaiei de mai jos:
Funcia este un program care poate s execute operaii complexe i care
furnizeaz un rezultat ce poate fi folosit ca operand ntr-o expresie.
3. Atribuii fiecrui tip de operator din prima coloan exemplul corect
prezentat n coloana a doua:
Numerici
&, +
Logici
>, <, >=,
<=, <>
Text
AND,
OR, NT
Relaionali +, -, *, /,
%
4. Macrocomanda este:

Dau rspunsurile la ntrebrile din test:

1.b
2.A
3. 1 4
23
31
42
4. O secven de comenzi de aciuni
supra unui obiect din baza de date
care se execut ca rspuns la un
eveniment declanat de acionarea
unui obiect de interfa.
5. F

test de parcurs

5. Stabilii valoarea de adevr a afirmaiei de mai jos:

Raportul este obiect container care grupeaz alte obiecte vizuale.
1 min
20 min

Captarea ateniei clasei i enunarea obiectivelor

Profesorul anun titlul leciei, obiectivele operaionale i modul de desfurare a
activitii.
Comunicarea noilor cunotine se realizeaz prin prezentarea leciei cu ajutorul
aplicaiei Ael.

Ascult profesorul i i noteaz n

caiete titlul leciei
Sunt ateni la explicaiile profesorului
i intervin n cazul n care au ntrebri.
Urmresc demonstraia realizat de
profesor.

conversaie
Conversaia,
explicaia

scris

Noteaz n caiete explicaiile oferite de

profesor.

Fixarea, retenia i transferul noiunilor predate prin aplicaii:

18 min

2 min

dialog Manager de Scenarii se pot administra scenariile create:

Efectueaz sarcinile de lucru.
tergere, Editare, Vizualizare, Sumar;
Se acioneaz butonul nchidere.
Se vor face aprecieri individuale i colective asupra activitii desfurate, elevii Elevii sunt ateni la aprecieri i la
recomandrile fcute de profesor.
care au activat n timpul orei sunt notai.

Exerciiul

Conversaia

Practic

Introducere

Voi ncepe cu un citat:

As soon as we started programming, we found to our surprise that it wasn't as easy to get
programs right as we had thought. Debugging had to be discovered. I can remember the
exact instant when I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs.
-- Maurice Wilkes discovers debugging, 1949
n traducere asta ar suna cam aa:
Imediat ce am nceput s programm am descoperit spre surprinderea noastr ca nu era aa
de uor s facem programe bune pe ct crezusem. Depanarea (debugging) trebuia s fie
inventat. mi pot aminti cu precizie momentul exact cnd am realizat c o mare parte din
viaa mea de atunci ncolo urma s fie petrecut n a gsi greeli n propriile mele
programe.
Regula de aur

Un program trebuie s fie scris n aa fel nct s poat fi citit de ctre oricine.
Programele sunt fcute n aa fel nct prile sunt strns dependente. Trebuie ca cele scrise
ntr-un loc s fie folosite ntr-altul (i eventual refolosite). Mintea unui om normal nu poate
reine toate amnuntele din textul unui program, de aceea trebuie s-i dm un ajutor.
Sfatul acesta este clar obligatoriu cnd se dezvolt soft n echip, pentru c ceea ce scrie
unul trebuie s fie folosit de altul. Paradoxal este c el este extrem de oportun chiar cnd
ntreg procesul de scriere este fcut de un singur programator. Nu vi s-a ntmplat niciodat
s v uitai la o funcie scris n urm cu o lun i s v mirai c ai putut scrie aa ceva?
Sau s v ntrebai ce face? Acel ``oricine'' din sfat poate fi deci un ``alter ego'' al
dumneavoastr.
Aparent scrierea ngrijit a unui program consum prea mult timp.
Pentru programe scurta acest lucru poate fi adevrat. Pentru programe la care lucrai mai
mult de o sptmn timpul cheltuit cu o scriere ngrijit este recuperat nzecit n fazele
ulterioare ale dezvoltrii (depanare, extindere, ntreinere). Dac nu credei, ncercai mcar
o dat.
mprirea programului

F bucile n aa fel nct s nelegi uor ce face fiecare fr a trebui s tii cum face.
Domnul Dijkstra (n olandez se citete aproximativ ``daicstra'') recomanda o tactic veche
de pe vremea lui Cezar: ``divide et impera'': ``mparte i stpnete''. Aa e bine s scriei i
programele: n buci ct mai independente unele de altele, care interacioneaz intre ele n
moduri ct se poate de clare i simple, i care nu se influeneaz ``pe la spate''.
Din fericire toate limbajele moderne de programare aduc un suport extrem de eficace
acestei metode de scriere: funciile, procedurile i modulele.
mprii deci programul dumneavoastr n astfel de pri ct mai des cu putin. Facei
prile logic independente; funciunea fiecreia trebuie s fie extrem de clar i ct se poate
de limpede enunat. De exemplu, o funcie care caut ceva ntr-un ir nu trebuie s fac i
ordonarea irului. Facei dou funcii independente pentru asta, una de cutare i una de
sortare.
Dac limbajul permite module, atunci facei-le n fiiere separate, ale cror nume s fie
suficient de clare. Grupai n fiecare modul numai funcii i variabile nrudite. Dac

programai ntr-un limbaj orientat pe obiecte, implementai fiecare clas ntr-un modul
separat, cu toate metodele ei. O s tii apoi unde s le cutai, i apoi o s le putei reutiliza
cu uurin n alte programe.
Cheia economiei de timp este asta: cnd vrei s foloseti o funcie trebuie s tii numai
ceea ce face; nu trebuie s o citeti n ntregime ca s vezi cum face acest lucru. De aceea
funcia este mult mai uor de folosit, i apoi poate fi la nevoie rescris n cu totul alt fel,
fr a influena ctui de puin restul programului. (De exemplu nu conteaz dac sortarea
este bubble sort sau quick sort, totul este s fie tot o sortare. Funciile care folosesc funcia
de sortare nu sunt interesate de modul n care aceasta se face). Un alt uria beneficiu al
acestei relative independene ntre feluritele pri este c n momentul n care un bug este
descoperit i scos dintr-una, celelalte vor rmne neschimbate, pentru c nu se bazau pe
felul n care lucra acea parte, ci doar pe ceea ce ea fcea.
Cte funcii sau linii de program trebuie s fie ntr-un modul? Asta este destul de mult o
chestie de gust, dar editorul de texte pe care l folosii poate influena mult alegerea. Dac
avei 24 de linii de ecran (din care 3 folosite la borduri i meniuri) este greu s scriei
fiiere mari, pentru c v plimbai cu greu prin ele. Alta este situaia dac avei 42 sau 80
de linii.
Un editor inteligent reduce handicapul unor fiiere mari, pentru c v permite s va mutai
cutnd automat apariiile funciilor i variabilelor.
Eu personal m descurc cel mai bine cu fiiere ntre 300 i 700 de linii, coninnd pn n
15 funcii.
Minima vizibilitate

Principiul minimei vizibiliti cere ca un obiect s nu fie vizibil dect prilor din program
care au cu adevrat nevoie de el. S vedem nite aplicri ale lui:
Datele trebuie separate ct se poate de mult de corpul programului.
O variant a acestei reguli este ``n sursa programului nu trebuie s apar nici un numr cu
excepia lui 0, 1, sau -1''. Constantele (n particular cele numerice) se mai numesc i
``magic numbers'' (numere magice). Ele trebuie evitate ntotdeauna.
Metoda comun este de a da nume simbolice constantelor undeva la nceputul fiecrui
modul, sau n fiiere speciale (cu const n Pascal i C, cu #define n C, etc.). Numele dat
unei constante are multe avantaje, care sunt expuse n mai toate cursurile de programare.
Noi vom reaminti dect pe unul: o constant face programul mult mai uor de citit. Aceasta
este o aplicare a principiului minimei vizibiliti: tii numai numele constantei (care trebuie
s arate la ce folosete ea), i nu valoarea ei!
Iat un exemplu:
for i:=1 to 128 do persoana[i].nume := '';

i tradus:

for p:=1 to NumarDePersoane do persoana[p].nume := '';

Nu e mai clar a doua oar?

Cum spuneam prile din program interacioneaz te miri cum. Cel mai adesea
interaciunile se fac prin variabile globale, a cror valori pot fi modificate de o funcie i
citite de alta.
De aceea este bine s transmitem funciilor (procedurilor) toate valorile de care au nevoie
prin argumente i s nu le lsm s modifice variabile globale.

Dac vi se pare greu s programai fr variabile globale, aflai c exist limbaje de

programare n care nu exist variabile de loc, i totui se pot face foarte multe lucruri (un
exemplu este Prolog; despre Prolog se crede ndeobte c are variabile, ns o analiz
atent va arta c ceea ce n Prolog se numete variabil nu folosete de loc la acelai lucru
ca o variabil n sensul uzual al limbajelor imperative ca Pascalul).
n realitate este foarte greu adesea s ne descurcm fr variabile globale, pentru c unele
funcii fac modificri att de masive nct ar trebui s aib zeci de parametri i s returneze
tot attea valori (ceea ce multe limbaje nici nu permit, dealtfel!). Tocmai pentru a
circumveni aceste dezavantaje au fost inventate limbajele orientate pe obiecte (alde C++),
n care n loc s dai unei funcii argumente, grupezi argumentele la un loc ntr-un obiect (un
fel de record din Pascal); funcia nsi devine un cmp al obiectului (se va numi ``funcie
membru''), i n loc s chemi funcia cu cmpurile obiectului ca argumente, rogi obiectul si aplice singur funcia.
Aceast reducere la maximum a vizibilitii din limbajele orientate pe obiecte (cci
cmpurile unui obiect sunt n mod normal accesibile numai funciilor care-i sunt membre)
se numete ``ncapsulare'' i constituie unul din avantajele majore ale programrii orientate
pe obiecte fa de cea ordinar.
Cu disciplin ns se pot aplica beneficiile ncapsulrii i n programe scrise n limbaje fr
astfel de construcii (C, Pascal), cu foarte mult succes.
Spaiile albe; i(n)dentarea

Unii separ prile din programe prin comentarii baroce ca:

{******************************}
{========intrare/iesire========}
{******************************}

1.
2.
3.
4.
5.
6.

Ei bine, puine spaii albe judicios plasate fac mult mai mult bine lizibilitii programului.
Iat care sunt recomandrile mele n ceea ce le privete:
Separai fiecare funcie de vecinele ei printr-o linie alb.
ntre titlul funciei i corpul ei eu las mereu un rnd n care pun de obicei comentarii.
ntre declaraiile variabilelor locale i corpul funciei las mereu o linie liber.
Punei mai multe linii, i eventual un comentariu de o linie de stelue ntre pri
majore ale programului.
Am observat c o expresie este mult mai uor de citit dac separ cu spaii unii
operatori de argumentele lor. Observai:
for(i=0;i<ultim;i++) if(!a[i]) total++;

fa de:

for (i = 0; i < ultim; i++) if ( ! a[i] ) total++;

7.

Pentru a uura depanarea este bine s punei o singur instruciune pe linie! Pentru
c linia de mai sus la depanare va executa ntreg ciclul for la o singur comand ``step'', iar
liniile de mai jos vor permite s vedei ce se ntmpl la fiecare pas:

8.
9.
10.
11.
12.
13.

for (i = 0; i < ultim; i++)

if ( ! a[i] ) total++;

Dac avei prea multe argumente la o funcie scriei aa:

venit(persoana[pozitie_curenta].nume,
departament[persoana[pozitie_curenta].cod_departament],
indexare_salarii);

14.

Dac trebuie s spargei o expresie pe dou linii lsai operatorul la nceputul celei
de-a doua linii.
15.
venit_max = persoana[pozitie_curenta].venit
16.
+ crestere_salariu;
17.
Logica expresiei rupte pe mai multe linii trebuie s fie clar:
18.
copii := numar_copii( indice[disc_curent, compartiment,
19.
raft_curent],
20.
eticheta);
21.
Nu calculai prea multe lucruri ntr-o singur expresie complicat, pentru c dup
aceea n-o s nelegei nici dumneavoastr ce ai vrut:
22.
i := 1;
23.
c := 'y';
24.
while (i < maxN) and not (a[i] < 0) and not (c = 'n') do begin
25.
i := i + 1;
26.
read(f, c)
27.
end
ci:
i := 1;
gata := false;
c := 'y';
while not gata do begin
if i >= maxN then gata := true;
if a[i] < 0 then gata := true;
if c = 'n'
then gata := true;
if not gata then begin
i := i + 1;
read(f, c)
end
end

28.

n englez ``to indent'' nseamn ``a zimui''. n romna s-a format barbarismul ``a
identa'' sau ``a indenta''. care nseamn a aranja frumos n pagin un program, n aa fel
nct structura lui s fie limpede. Mai toate limbajele moderne sunt indiferente la numrul
de spaii, aa c folosii-le ca s indicai structura programului. Exemple se gsesc i mai
sus.
Regula de baz este ca o instruciune care depinde de alt instruciune s fie scris puin
mai la dreapta. De pild if arat aa: if <expresie> then <instructiune1> else
<instructiune2>.<instructiune1,2> depind de if. Un if se scrie deci aa:
if TrebuieSters then
StergeJucator(BazaDeDate, NumarulDeOrdine)
else
calificari(BazaDeDate, NumarulDeOrdine);

29.

Dac instruciunea dependent este o instruciune bloc, avei mai multe posibiliti
de a o aranja n pagin. Totul e s alegei una i s o respectai mereu.
30.
for i := 1 to ultim do begin
31.
CalculeazaNota(i);
32.
AlegePostura(i)
33.
end;
sau

for i := 1 to ultim do
begin
CalculeazaNota(i);
AlegePostura(i)
end;

sau

for i := 1 to ultim do
begin
CalculeazaNota(i);
AlegePostura(i)
end;

sau
for ( i = 1; i <= ultim; i++)
{
calculeaza_nota(i);
alege_postura(i);
}

34.

Ct de multe spaii trebuie s se foloseasc pentru a indenta? 1 este prea puin, i

structura programului nu apare suficient de clar, 8 este prea mult, pentru c la o indentare
de 4 nivele nu mai ajunge ecranul. Cel mai bine este ntre 2 i 6.
35.
Etichetele de la goto sau case se indenteaz puin mai n stnga:
36.
repeta:
37.
switch(raspuns) {
38.
case 'd':
39.
stiut = DA;
40.
break;
41.
case 'n':
42.
stiut = NU;
43.
break;
44.
case '?':
45.
interogare();
46.
goto repeta;
47.
default: /* alt raspuns */
48.
return;
49.
}
50.
Construciile de genul else if sunt o excepie de la regula de indentare. Ele pot fi
scrise n loc de:
51.
if e1 then cutare1
52.
else
53.
if e2 then cutare2
54.
else
55.
if e3 then cutare3
56.
else cutare3
aa:
if e1 then cutare1
else if e2 then cutare2
else if e3 then cutare3
else cutare3

pentru c sunt echivalente cu un case din Pascal (switch din C) -- adic un if cu mai multe
condiii, care au aceeai importan.
Comentariile

Comentariile sunt ntr-adevr extrem de utile pentru a uura nelegerea funcionrii unui
program. Rolurile lor sunt multiple, i modul n care se pot folosi extrem de variat.
n primul rnd exist dou feluri de comentarii:
comentarii de linie
comentarii de sfrit de linie
Primele ocup o linie (sau mai multe) de program n ntregime i explic ceva din
Variabilele, constantele, funciile, procedurile

Dac nu poi s-i dai un nume unei variabile nseamn c acea variabil nu este bun.
Reconsider arhitectura ntregului program.
ntr-adevr, nu trebuie s faci nici un efort ca s-i aduci aminte ce reprezint o variabil;
numele ei trebuie s-i spun tot ce te intereseaz.
Nu facei niciodat economie nghesuind n aceeai variabil mai multe valori, depinznd
de context! Fiecare variabil trebuie s reprezinte un singur lucru n fiecare clip.
Compilatoarele moderne sunt suficient de inteligente ca s transforme cele dou variabile
n una singur dac asta se poate! (De fapt le chiar uurai munca nenghesuind mai multe
lucruri laolalt).
Numele unei variabile trebuie s arate exact ce reprezint valoarea ei.
Numele variabilelor, funciilor, procedurilor, argumentelor lor, trebuie s fie de asemenea
uor de reamintit. Dac scrii un program i trebuie mereu s te duci la prima pagin ca s
vezi dac o variabil se cheam max_n. sau max_numere sau maximum_numere treaba merge
destul de greu. n principiu nu se folosesc prescurtri. Un nume de variabil
ca x sau total este absolut inutil, cci orice poate fi x.
Scrieix_fereastra sau total_venit de pild.
Nu trebuie s va fie lene s tastai. De altfel un editor foarte bun (ca de exemplu GNU
Emacs) v ajut foarte mult (Emacs la apsarea tastei M-/ ncearc s completeze cuvntul
curent cu un sufix care se regsete undeva prin text. De pild dac am definit
variabila complexitate_totala. atunci probabil ajunge sa tastez com i apoi M-/ ca Emacs s
completeze ntreg numele).
Nu scriei funcii care n funcie de un argument fac dou lucruri diferite:
int operatie(FILE * f, struct persoana * p, int actiune)
/* daca actiune = 0 -> cauta de cite ori apare persoana p in fisier
* daca actiune = 1 -> sterge toate aparitiile p din f
*/

Scriei dou funcii, pe care le chemai dintr-un if sau switch (case).

Este util s folosii notaii diferite pentru constantele numite pentru a le distinge de
variabile. n C, n care conteaz literele mari/mici, aceste constante au de obicei numele
scrise numai cu majuscule.
Un program cu nume de variabile eficient alese are nevoie de mult mai puine comentarii,
i este mult mai uor de citit i ntreinut. Cineva spunea c pot fi citite la gura sobei, ca o
carte bun. Am avut ocazia s citesc astfel de programe i trebuie s recunosc c am nvat
extrem de mult din ele. Pentru curioi recomand doi montri sacrii ai programrii cristaline,

Andrew S. Tanenbaum (autorul sistemelor de operare MINIX i Amoeba) i Richard

Stallman (autorul compilatorului GCC i al lui GNU Emacs).
Dac scriei module care export multe variabile sau funcii putei prefixa toate obiectele
unui modul cu un text care le arat proveniena i semnificaia. De exemplu toate
procedurile care lucreaz cu ferestre se vor numi ceva de genul Win_xxx (win de la
``window''.. Aceasta complic i simplific deopotriv unele lucruri. E mai simplu pentru
c poi avea o procedur make i pentru ferestre, i pentru stive, numai c una se
cheam Win_make iar alta Stk_make.
Dac v decidei pentru prefixe, n general ele sunt preferabil sufixelor. Adic e mai
bine Win_make dect make_win. pentru c prefixele se vd mai uor. n nici un caz nu
amestecai ntr-un program cele dou feluri de numire.
Apropos de amestecare, facei la nceput nite decizii de numire omogen a obiectelor cu
care operai. De exemplu: ``toate comentariile sunt n englez'', sau ``toate numele de
proceduri sunt cuvinte englezeti'', .a.m.d. n program coexist greu o
procedur numar_persoane cu una first_person. (Dac nu tii englez lucrurile sunt ceva
mai simple.)
Fiabilitatea

``Nu avea ncredere n nimeni, nici mcar n tine nsui!'' Respectarea acestei reguli aduce
nite beneficii greu de imaginat. Ce nseamn ea pentru un programator?
1.
Funciile nu trebuie niciodat s se bazeze pe cel care le cheam, cum c le
furnizeaz argumente corecte. Verificai toate argumentele nainte de a le prelucra; dac nu
sunt corecte anunai eroarea, fie scriind ceva pe ecran, fie returnnd o valoare indicnd
eroare utilizatorului.
2.
Funciile nu trebuie s se bazeze niciodat pe cele pe care le cheam. De fiecare dat
cnd ai chemat o alt funcie verificai dac nu cumva a semnalat o eroare. Dac da
acionai n consecin, i oprii procesarea.
3.
Un caz particular al lui 2. este apelul unor funcii din biblioteci. Mai ales cele care
fac intrare/ieire pot eua din zeci de motive. Verificai mereu dac au funcionat nainte de
a v arunca cu capul nainte. Dac v e lene, scriei funcii ``nveli'' (``wrappers'') care le
cheam pe cele de bibliotec i care verific erorile. Folosii apoi numai wrapper-ele. De
exemplu:
4.
void * aloca_memorie(size_t marime)
5.
/* aloca memorie. eroare fatala daca nu mai este memorie */
6.
{
7.
void * p; /* aici alocam temporar */
8.
9.
p = malloc(marime);
10.
if (p == NULL) {
11.
/* standardul spune ca malloc intoarce NULL numai
12.
* daca nu a reusit sa aloce cantitatea indicata */
13.
fprintf(stderr, " Alocare nereusita!\n");
14.
exit(1);
15.
}
16.
return p;

17.
}
sau (n TURBO-Pascal):
procedure deschide_fisier(var f:text; nume:string);
{ deschide un fisier; verifica erorile }
begin
{$i-}
{ inhiba erori de executie pentru intrare-iesire }
assign(f, nume);
reset(fis);
{$i+}
{ inversul lui $i- }
if ioresult <> 0 then begin
writeln('deschide_fisier: Nu pot deschide fisierul ', nume);
halt
end
end;

18.

Din loc n loc introducei verificri asupra datelor pe care le prelucrai, chiar dac vi
se par inutile. n C exist funcia standard assert care este extrem de util, dar putei scrie
i n Pascal una asemntoare. Aceast funcie oprete definitiv programul dac este
chemat cu un argument 0. Frumuseea este c toate invocrile lui assert sunt scoase
definitiv din program doar definind macro-ul NDEBUG.
Metoda universal este urmtoarea: definii constanta boolean (sau ntreag) DEPANARE, pe
care o facei true. Apoi n program verificai mereu astfel:
if DEPANARE then begin
{ verificam daca locasele sunt bine initializate }
for i := 1 to spatii do
if locas[i].urmator = nil then begin
writeln('Locas cu "urmator" nil la indicele ', i);
halt
end
end

Testele pentru locae se vor efectua numai dac DEPANARE este true. Dac
facei DEPANARE false, testele dispar cu desvrire! Putei astfel s v depanai programul,
iar cnd merge s-l scurtai. Un compilator cu optimizri va observa c liniile de test nu se
vor putea efectua niciodat (pentru c DEPANARE este o constant), i le va scoate cu totul
din program. (Pe de alt parte unele teste este nelept s rmn pentru totdeauna n
program; nu se tie niciodat pentru ce date de intrare programul o ia razna. Este
recomandabil s gseti o eroare ct mai repede i s urlii c ai gsit-o dect s o ignori o
vreme i ea s fac prpd n linite. Muli utilizatori vor aprecia.)
19.
Distingei n programele dumneavoastr (cel puin) dou tipuri de erori: fatale i
recuperabile. Scriei dou funcii care trateaz aceste tipuri de erori. Toate erorile ar trebui
s indice ct mai clar locul unde s-au produs: numele programului, numele modulului,
numele funciei, tipul erorii. La depanare nu ajut prea tare dac vezi ceva de genul:
``eroare de intrare/iesire''. Mai bine e ``statistic: functia `citeste_data': eroare: nu pot
deschide fisierul `info.txt'''.
Tocmai din aceast cauz nu orice eroare trebuie semnalat ca fiind fatal. Nu poi s faci o
mprire la 0? Anun doar pe funcia care te-a chemat cu argumente greite c ceva nu e
n regul. Cum ar fi un program de calculator de buzunar care s-ar opri la o astfel de
eroare? Penibil! Eroarea trebuie doar s fie anunat i procesarea continuat.
Poate vom reveni cu un articol special despre tratamentul erorilor, pentru c este un subiect
extrem de interesant, i foarte prost tratat n literatur. O eroare se poate adesea propaga n

sus pe un lan de funcii care s-au chemat ntre ele (mai ales dac una era recursiv) la
distane extrem de mari de locul producerii. Cum se face asta cu grij, cum se semnaleaz
erorile cel mai simplu, asta merit discutat mai pe-ndelete.
Documentaia

1.
2.
3.
4.
5.
6.
7.
8.

Donald Knuth (unul din cei cu citatele din introducere) este unul dintre adepii a ceea ce se
numete ``litterate programming''. Acesta este un sistem (numit Web) n care programul i
documentaia sa se scriu dintr-un singur foc, apoi cu dou compilatoare diferite se obin
executabilul i cartea de descriere a produsului. Paradoxal, aceast metod mrete
productivitatea i fiabilitatea, pentru c i poi introduce explicaiile detaliate chiar n
corpul programului n timp ce-l scrii, gndind mai uor att asupra programului ct i
documentaiei.
Dac nu spunei cum face ceva un program de-al dumneavoastr, trebuie totui s
spunei ce face. Chiar dac nu scriei programe pentru vnzare este un obicei extrem de util
s scriei scurte documentaii pentru utilizatorii lor sau cei care vor s le modifice. Un
model mpmntenit este pagina de manual interactiv din UNIX (sau comanda ``help'' din
DOS, ntr-un fel). O descriere a programului dumneavoastr ar trebui s conin
urmtoarele informaii:
numele programului;
modul de lansare (argumente, etc);
o descriere a comportrii;
pentru programe interactive indicaii sumare de folosire;
informaii despre fiierele pe care le folosete i structura lor;
versiunea curent;
autorul programului cu adresa lui (nu se recomand dac programul este un virus);
defeciuni cunoscute;