[so] In legatura cu corectarea
Octavian Purdila
so@atlantis.cs.pub.ro
Fri, 21 Nov 2003 10:08:17 +0200
On Thu, 20 Nov 2003 14:00:25 -0800 (PST), Sava Ionut
<sava_ionut@yahoo.com> wrote:
> Eu as propune asta : sa se spuna cam care vor fi
> testele ( cel putin mai vag ) sau anume la ce sa fim
> atenti. Cu alte cuvinte ar trebui sa fim un pic
In primul si in primul rand ar trebui sa cititi modalitatea
de punctare, si mai ales de depunctare din sectiunea
Reguli. Daca exista neclaritati, la cum puteti detecta
situatiile descrise acolo, intrebati pe lista.
Aproape toate greselile pentru care au fost depunctate
majoritatea temelor sunt intalnite in acea lista.
In al doilea rand: testati-va temele singuri. Contrar a ceea
ce cred unii, nu e nevoie de mii de teste pentru a va verifica
programul.
Daca aveti clara arhitectura programului este simplu sa testati
componentele acestuia, si sa eliminati bugurile evidente. In
cazul primei teme acest lucru era banal, pentru ca fiecare
comanda putea fi testata separat.
Testarea temei este la fel de importanta ca si implementarea ei,
asa ca noi consideram ca este mai bine sa nu va dam
testele, astfel incat voi sa va ganditi la ele, si prin acest lucru
sa intelegeti mai bine tema.
> ajutati sa gasim bugurile ca sa putem rezolvam, mai
> degraba decat sa vedem ca suntem depunctati. Eu
> personal nu cred ca cineva dupa ce isi vede tema
> corectata se apuca sa isi corecteze bugurile, deci cu
> alte cuvinte nu prea invata multe.
>
Nu e atat de important sa corectati bugurile unei teme
ce a fost notata deja, decat ca exercitiu. Dar e important
sa intelegeti de ce a aparuta bugul, si cum puteti
evita situatii de genul acesta in viitor. Stiti voi,
errare humanum est, perseverare diabolicum.
> De asemenea ar fi sa se faca pentru fiecare tema o
> lista de greseli frecvente si cum se pot rezolva (
> eventual si cod dc nu depaseste 5-6 linii). Sau sa fie
Cea mai frecventa "greseala" este faptul ca nu se
programeaza cu pagina de manual in fata. Inainte de a folosi
o functie, cititi cu atentie, si pe cat posibil, toata
pagina de manual si luati in calcul toate posibilitatile oricat
de improbabile ar parea ele.
In plus, exista un stil de programare ce duce inevitabil la
buguri: fixarea unor limite. Uneori acest lucru este
inevitabil, dar in aceste cazuri tineti cont de limite.
Aceste greseli sunt cauza a probabil 90% din buguri.
> puse pe site un numar de teme facute f bine ca sa
> putem sa ne comparam (Chiar daca toti ar face o tema
> perfect tot ar fi unele care sa fie facute optimizat,
> cu mai putine linii de cod, mai elegant ... SI TOT AR
> FI O SANSA IN PLUS SA INVETI CEVA).
Acest lucru este imposibil, in situatia in care temele sunt valabile
inclusiv in sesiunea de restanta.
> De exemplu am vazut la mai multi oamneni nu se
> inchidea pipe-ul. Nu stiam ca trebuia inchis capatul
> de scriere al pipeului inainte de exec. Si probabil dc
> nu auzeam pe cine trebuie nici n-as fi aflat prea
> curand.
Sunt curios: ai fost la laborator?
tavi