O eroare (bug) este o eroare în hardware sau software care determină ca un program să fie executat altfel decât este prevăzut. Depanarea (debugging) înseamnă eliminarea erorilor din hardware sau software.

DE UNDE VINE TERMENUL BUG?

Există diverse explicații ale etimologiei cuvântului ”debug”, utilizate în programarea computerului, de la povești apocrife despre molii care se găsesc în plăcile de circuite ale computerelor defectuoase, până la cuvântul care provine din mitologia bugbear, o fiară nedorită. Dar, de fapt, termenul bug a fost folosit pentru a însemna ceva tulburător de secole. Pentru mai multe informații, căutați termenul „bug” pe un site cum ar fi Free On-line Dictionary of Computing, http://foldoc.org/.

Obiectivul depanării este de a elimina toate erorile din cod. Ordinea operațiilor ar putea fi următoarea:

1. Mai întâi se testează codul pentru a vedea dacă funcționează așa cum trebuie, executând procedura o dată sau de două ori utilizând fișiere adecvate sau date adecvate. Încercați toate opțiunile pe care macrocomanda le pune la dispoziția utilizatorului. Chiar dacă pare să funcționeze, continuați testarea pentru o perioadă rezonabilă cu diverse date din diverse documente-eșantion înainte de a lansa procedura în lume (sau pentru colegii dvs.).

2. Dacă codul dvs. nu funcționează așa cum vă așteptați, va trebui să îl depanați. Aceasta înseamnă urmărirea tehnicilor descrise în acest capitol pentru localizarea erorilor și apoi eliminarea lor. După ce ați eliminat toate erorile pe care le puteți găsi, testați codul din nou așa cum este descris în primul pas. Acest lucru este important, deoarece uneori, actul de depanare în sine introduce noi bug-uri.

3. Când testați codul, încercați să anticipați modalități neobișnuite, poate exotice, prin care utilizatorii ar putea folosi codul dvs. De exemplu, s-ar putea să scrieți o procedură sofisticată pentru manipularea unui document Word cu presupunerea (perfect rezonabilă) că documentul va fi deschis atunci când utilizatorul începe execuția procedurii. Îl puteți testa pe documente de probă până când va funcționa bine de fiecare dată. Dar dacă un utilizator încearcă să ruleze procedura fără să deschidă mai întâi un document, procedura se blochează.

Și nu te amuza pe seama acestui utilizator. Utilizatorii ar putea să înțeleagă că procedura ar trebui să fie lansată înainte de încărcarea unui fișier. Utilizatorii s-ar putea aștepta ca procedura să afișeze o casetă de intrare, întrebându-i ce document doresc să manipuleze. Și mai important, utilizatorii se așteaptă, de asemenea, că veți anticipa și gestiona erorile neașteptate fără ca programul să se blocheze. Există modalități de a captura comportamentul utilizatorului neanticipat sau alte erori de rulare și de a le răspunde frumos. De exemplu, ce face programul dacă utilizatorul încearcă să salveze un fișier în altă locație? Se va bloca și se vor pierde toate informațiile pe care le-a tastat?

4. Când sunteți gata să distribuiți procedura, este posibil să doriți să scrieți instrucțiuni pentru utilizarea acesteia. În aceste instrucțiuni, poate fi necesar să descrieți eventualele erori pe care nu le puteți repera sau circumstanțele în care procedura nu ar trebui să fie executată. Dar este mai bine să construiți instrucțiuni, răspunsuri la probleme neanticipate și alte tipuri de erori care să fie detectate de macrocomandă. Încercați să faceți codul dvs. impermeabil.

Depanarea unei proceduri tinde să fie idiosincratică. Nu există bagheta magică cu care să atingi codul pentru a alunga erorile (deși Editorul VBA face tot posibilul să vă ajute să eliminați anumite tipuri de erori din cod pe măsură ce îl creați). Mai mult, astfel de lucruri simple, cum ar fi uitarea inițializării unei variabile, pot face ravagii în cod.

Probabil veți dezvolta propria abordare de depanare, în parte deoarece programarea dvs. va fi scrisă în mod inevitabil în propriul dvs. stil. Însă, atunci când depanați, vă ajută să vă concentrați asupra a înțelege ceea ce se presupune că va face codul. Apoi, corelați acest lucru cu observațiile dvs. despre ceea ce face efectiv codul. Când le reconciliați pe cele două, probabil că veți fi rezolvat modul de depanare a procedurii.

De asemenea, cu cât codul este mai lung și mai complex, cu atât este mai mare probabilitatea ca acesta să conțină erori. Anumite tipuri de bug-uri apar din cauza interacțiunilor dintre părțile unui proiect. Și, evident, cu cât este mai mare proiectul, cu atât sunt mai multe părți cu efecte secundare potențiale, deci păstrați-vă codul cât mai simplu, împărțindu-l în proceduri și module separate, așa cum este discutat în secțiunea „Construirea codului modular și utilizarea claselor”. Secțiunile mici de cod cu sarcini distincte și mici de îndeplinit sunt aproape întotdeauna mai ușor de depanat decât secțiunile mari de cod care încearcă să facă mai multe lucruri simultan. Nu uitați că cea mai mare depanare este de a localiza unde apare problema în cod. Dacă testați un mic modul de cod cu un obiectiv foarte ușor de specificat, localizarea unei erori este mult mai ușoară.