Lecție-punte: depanarea de bază

Ideea-cheie

Un bug (o greșeală în program) este diferența dintre ce CREZI că face codul tău și ce face EL de fapt. Tu ai în minte o poveste: „citesc trei numere, le adun, afișez suma”. Calculatorul însă nu citește povestea din mintea ta — el execută strict literele pe care le-ai scris. Bug-ul trăiește fix în spațiul dintre cele două.

De aceea regula de aur a depanării este: îl prinzi observând, nu ghicind. Atâta timp cât doar bănuiești ce s-a stricat, repari pe orbecăite. În clipa în care VEZI valoarea reală dintr-un anumit punct, greșeala nu mai are unde să se ascundă.

Înainte de orice reparație, lămurește ce fel de problemă ai — sunt două foarte diferite:

• Eroare de compilare — programul nici nu pornește. Ai uitat un ;, o paranteză, ai scris greșit un nume. Calculatorul îți spune chiar el unde: citește mesajul și numărul liniei din el; acolo, sau cu un rând mai sus, e problema.
• Rezultat greșit — programul pornește, rulează frumos până la capăt, dar afișează alt răspuns decât cel corect. Aici nu primești niciun mesaj de ajutor; trebuie să cauți singur unde s-a abătut.

Prima se rezolvă citind. A doua se rezolvă observând — și despre ea e restul lecției.

Cum alegi: strategia în trei pași

Când programul rulează dar dă un răspuns greșit, nu te apuca să rescrii la întâmplare. Mergi pe pași, de la simplu la sigur:

1. Reproduci pe un exemplu mic. Nu vânezi bug-ul pe un test cu o mie de numere. Iei trei valori pe care le poți calcula tu în cap, ca să știi exact care e răspunsul corect. Dacă greșeala apare și acolo — perfect, ai un caz mic pe care îl poți studia.
2. Afișezi valori intermediare cu cout. Pui o afișare în mijlocul codului ca să vezi negru pe alb ce valoare are o variabilă în acel punct. Așa compari ce te așteptai cu ce e de fapt și prinzi exact rândul unde realul se desparte de așteptarea ta.
3. Urmărești manual fragmentul suspect. După ce ai restrâns problema la câteva rânduri, le parcurgi cu creionul, pas cu pas, exact ca la lecția de urmărire manuală — și de obicei vezi cauza cu ochiul liber.

Un exemplu concret

Vrei să citești trei numere și să afișezi suma lor. Scrii:

#include <iostream>
using namespace std;

int main() {
    int a, b, c;
    int suma;          // BUG: nu am dat nicio valoare de start
    cin >> a >> b >> c;

    suma = suma + a;
    suma = suma + b;
    suma = suma + c;

    cout << suma;      // afiseaza un numar ciudat, nu 12
    return 0;
}

Pentru a=3, b=4, c=5 te aștepți la 12. Programul afișează însă un număr uriaș și fără sens, diferit de fiecare dată. Programul a rulat — deci nu e eroare de compilare; e rezultat greșit.

Aplici strategia. Exemplul e deja mic (3, 4, 5), știi că răspunsul corect e 12. Acum afișezi o valoare intermediară — chiar la început, înainte de prima adunare:

int suma;
    cout << "suma la start = " << suma << "\n";   // afisare de control
    cin >> a >> b >> c;

Rulezi și vezi: suma la start = 4197328 (sau orice alt număr aiurea). Aici e declicul. Tu credeai că suma pornește de la 0. De fapt o variabilă căreia nu i-ai dat nicio valoare conține un gunoi rămas în memorie. Toate adunările tale corecte pleacă de la acel gunoi, așa că suma finală e gunoi + 12.

Acum că ai VĂZUT cauza, repararea e o singură literă de adevăr — pornești acumulatorul de la zero:

int suma = 0;     // acum stim sigur de unde plecam

Observă ce a făcut acel cout: nu a reparat nimic singur, dar a transformat o bănuială („poate e ceva cu suma?”) într-o certitudine văzută cu ochii. După ce ai înțeles cauza, ștergi afișarea de control — și-a făcut treaba.

Pe scurt: un bug e distanța dintre ce crezi și ce face codul, iar îl prinzi observând (exemplu mic + cout + urmărire), nu ghicind. Întâi vezi cauza cu ochiul tău, abia apoi repari — altfel cârpești simptomul și strici altceva.