Questo articolo è rivolto a chi NON SA USARE O NON SA COSA SIA un debugger perchè o non ha mai avuto necessità di farlo e/o non gli è stato mai stato insegnato.

Cos'è il debugger?

Il debugger è un programma utilissimo, disponibile per tutti i linguaggi di programmazione disponibili (e spesso per ognuno più di uno) che serve per aiutarci a trovare i nostri errori nei programmi:

in pratica ci aiuta a rispondere alla domanda: "dove crasha il mio programma?" e successivamente: "dove è l'error?" o "dove ho sbagliato?" o "cosa ho dimenticato?" e così via...

Come lo fa?

Il debugger svolge il suo compito consentendoci di controllare il flusso di esecuzione del nostro programma e il valore delle variabili e/o memoriache il nostro programma utilizza.

Gli strumenti che ogni debugger mette a disposizione sono:

• breakpoint
• pausa
• riprendi
• step
• guarda memoria

In questo articolo prenderò come esempio il debugger integrato di visual studio perchè facile da usare, da capire e perchè può essere usato per debuggare VB.NET, C# e C/C++!

Ovviamente siete liberi di usare il debugger che più preferite...

Come si usa

Per usare il debugger dobbiamo informare il compilatore che stiamo generando un eseguibile contenente informazioni di debug.

In Visual Studio basta scegliere un build target con "Debug" es: x86 (Debug).

Una volta generato normalmente il nostro eseguibile invece di aprire la cartella contenente il nuovo eseguibile facciamo click sul pulsantino verde a forma di freccetta (Quella che chiamiamereste "play").

Bene.. Cosa è cambiato? Proprio nulla! Eh già: il programma non ha breakpoints (o punti di interruzione) quindi l'esecuzione del programma è uguale a quando non si utilizza il debugger.

Ora inseriamo un breakpoint facendo click sul lato sinistro della riga contenente l'istruzione alla quale il debugger deve fermare l'esecuzione delprogramma: vedremo apparire un punto rosso gigante: quello significa che in quell'istruzione è stato posizionato un breakpoint, e che, in fase di debug, quando il programma dovrà eseguire quell'istruzione il debugger lo fermerà e ci consentirà di fare diverse cose.

Fermi ad un breakpoint

Quando un programma è fermo ad un breakpoint possiamo visualizzare la memoria del programma! Con Visual Studio potete posizionarvi sopra il nume di una variabile con il cursore del mouse e dopo qualche istante vedrete comparire tutte le informazioni che vi servono su quella variabile: anche se è un array, una matrice, una lista, un oggetto o qualsivoglia altro tipo di struttura!

Per una visualizzazione futura più veloce di quella variabile consiglio di aggiungerla alla lista di variabili osservate (tasto destro del mouse "add to watch").

Memoria visualizzata

Ora che abbiamo raccolto tutte le informazioni che dovevamo raccogliere possiamo continuare l'esecuzione del programma.

Tuttavia abbiamo due opzioni: riprendere la normale esecuzione che potrà portare ad un nuovo breakpoint o eseguire SOLO l'istruzione ATTUALE (ricordo che il debugger si ferma PRIMA di eseguire l'istruzione designata dal breakpoint e che tale istruzione è l'istruzione attuale perchè puntata dal program counter) OPPURE riprendere la normale esecuzione del programma.

nel primo caso dovrete utilizzare step (freccetta gialla davanti alla freccetta verde), nel secondo caso si riprende l'esecuzione del programma con lo stesso comando con cui la si è iniziata (freccetta verde).

Ripetere

Ripetete i precedenti passi per capire esattamente dove il programma crasha o manifesta comportamenti inaspettati.

Una volta capito il punto "problematico" si procede a controllare la memoria coinvolta in tale risultato e ne si guarda la storia per trovare l'errore.

Trucchi

Ogni programmatore ha i sui trucchi per rendere le sue sessioni di debug più efficaci, personalmente io utilizzo una tabella che chiamo: "tabella di rompimenti e seccature" rompimenti da "breakpoints" e seccature perchè le colonne indicano le variabili/oggetti/strutture/memoria con risultati/valori errati.

1. Spargere dei breakpoint nei punti "interessati" dal malfunzionamento (es. r1, r2, r3)
2. Identificare le variabili interessate dal malfunzionamento (es. addendo1, addendo2, risultato)
3. prendere un foglio di carta e costruire una tabella del tipo:

  r    |  addendo1 |   addendo2     |    risultato    

+---+-------------+----------------+----------------

| r1 |     5           |        6            |       12          

+---+-------------+----------------+----------------

| r2 |      6          |        12          |       19          

+---+-------------+----------------+----------------

| r3 |     19          |        12         |       32          

+---+-------------+----------------+----------------

E poi la guardo bene...... Ehi! Perchè il risultato è sempre di 1 più grande di quello che mi aspettavo?!?!?!? <= problema identificato e messo a fuoco

Ah! Ecco! Lì c'è un '+1' che non doveva esserci! <= problema risolto!

Conclusioni

Se con il debugger non riuscirete a risolvere i problemi dei vostri programmi significa che siete poco allenati a farlo, ma non vi scoraggiate: nessuno è mai nato imparato! 

Inoltre se chiederete aiuto in un qualsiasi forum o ad una qualsiasi persona riuscirete ad indicare almeno il punto di partenza dal quale cominciare a cercare l'errore, e questo è importantissimo:

• risparmierete molto tempo
• risparmierete molta fatica
• dimostrerete che ci tenete a risolvere i vostri problemi

E di conseguenza le persone saranno più inclini ad aiutarvi, specialmente se il programma è complesso/non banale!