Debug: che cos’è, cosa vuol dire e quali tecniche esistono

Debug: che cos’è, cosa vuol dire e quali tecniche esistono? La parola di suo ha un significato tutt’altro che tecnichese, è nata proprio per via degli insetti. In questo articolo scopriremo nel dettaglio tutto questo.

Debug: che cos’è, cosa vuol dire e quali tecniche esistono? Partiamo dalla definizione: De-Bug letteralmente in inglese significa “rimozione degli insetti”.

Questo termine deve la sua nascita a un fatto a dir poco spiacevole.

Dobbiamo tornare nel lontano 1940 all’Università di Harvard.

Ciao mi chiamo Lorenzo Neri e sono un informatico: realizzo contenuti per aiutare le persone a padroneggiare l’arte del nuovo millennio, ovvero l’informatica!

Un’impegnata Admiral Grace Hopper, stava cercando di capire come mai il computer Mark II avesse dei problemi durante l’esecuzione di un programma: non le tornavano i conti.

A quei tempi i computer erano tutt’altro che minuscoli: occupavano stanze intere e i circuiti di cui erano composti erano fatti da componenti enormi se paragonati ai computer di oggi!

Così Admiral decise di aprire il computer per capire cosa ci fosse di strano.

Ci trovò una falena.

Su un relè.

Ovviamente, la rimosse per far tornare il computer al suo funzionamento originale.

Da allora, fu coniato il termine “debug” e il suo significato si rifà a questa storia.

Oggigiorno per fortuna non abbiamo falene che volano dentro i nostri computer, ma il debug consiste nello scovare gli errori all’interno del codice per farlo funzionare correttamente.

Ecco che cos’è il “debug”, ma naturalmente si è evoluto.

Esistono differenti tecniche di debug e in questo articolo, scopriremo quali sono!

Debug: quali tecniche esistono?

Tra le varie tecniche, partiamo da una delle più semplici, anche perché è una delle prime che si impara quando si vuole imparare a programmare!

Stampa a video

Vediamo una delle tecniche di debug più comuni.
Può capitare che per distrazione o per convinzione personale siamo sicuri al 100% che una parte del nostro codice sia giusta in ogni sua parte.

Gli diamo in pasto dei dati e ci aspettiamo di ottenerne altri in uscita.

Ma non quelli desiderati.

Come fare quindi, a capire dove sta l’errore nella nostra porzione di codice?

Il trucco è inserire una riga che stampi a video i valori delle variabili, in modo tale da capire come queste vengano modificate:

console.log("la variabile pippo vale"+pippo);

Durante l’esecuzione, avremo dei messaggi stampati a video che ci faranno capire dove i conti non tornano.

Questa tecnica è efficace non solo per capire i valori assunti dai dati, ma anche per verificare se le nostre condizioni sono state scritte correttamente, oppure no.

Hai già capito cosa intendo? 😉

Sto parlando degli if-then-else.

Inserire delle stampe a video al loro interno, ci fa capire quando viene eseguito un ramo piuttosto che un altro:

if (k==1){
   console.log("la variabile k vale 1");
}
else{
   console.log("la variabile k non vale 1");
}

Breakpoint

Questa è una delle tecniche di debug che può aiutarti di più per evitarti grosse perdite di tempo 😀

Se non hai mai sentito questa brutta parola in vita tua, preparati perché stai per scoprire uno strumento magnifico!

In alcuni ambienti di sviluppo, i breakpoint permettono la sospensione temporanea dell’esecuzione del programma.

Questa tecnica purtroppo non si presta troppo bene con i linguaggi interpretati, con i linguaggi compilati funziona benissimo!

Come funziona il breakpoint

Solitamente, a sinistra del numero di riga del nostro codice, potrai notare che c’è un piccolo spazio, ci hai mai cliccato?

Questi sono i breakpoint: dall’inglese “punto di sospensione”.

Il breakpoint, come dicevo prima, sospende l’esecuzione del programma alla riga selezionata, ma non solo.

Oltre a sospendere l’esecuzione, ti permette di monitorare i valori delle variabili in tempo reale rispetto al punto del codice in cui hai inserito il breakpoint.

Il breakpoint torna molto comodo per verificare se le variabili hanno i valori che ti aspetti oppure no.

È molto probabile che tu abbia una domanda in informaticoa:

“Lorenzo ma che differenza c’è tra usare il breakpoint e la stampa a video?”

La stampa a video viene eseguita se ovviamente non ci sono errori gravi.

Cosa intendo per errori gravi?

Variabili non valorizzate (poste a null), eccezioni, overflow, insomma: qualsiasi cosa che possa far crashare il programma.

L’uso dei breakpoint ti permette di capire dove e perchè crasha il programma.

Watch

Lo sapevi che, in aggiunta al breakpoint se non hai voglia di diventare pazzo con il cursore del mouse a guardare tutte le variabili una per una puoi usare la magia dello strumento “watch”?

Il watch, se non l’hai mai visto nel tuo ambiente di sviluppo, è uno strumento che ti permette di tenere d’occhio le variabili in tempo reale in base ai breakpoint inseriti.

È sufficiente scrivere il nome della variabile, inserire il breakpoint dove credi sia più opportuno et voilà!

Se te lo stessi chiedendo, funziona alla perfezione anche con oggetti, liste, array e matrici 😀

La watch è una tecnica di debug avanzata e spesso poco considerata specialmente se sei alle prime armi, ma guarda quanto è bella 😀

Catturare le eccezioni

Fra le tecniche di debug esistenti, questa torna molto comoda ed è rapida! Specialmente se programmi in C# o Java 😀

Può capitare diverse volte che il programma vada in crash, smetta di rispondere o si chiuda senza alcun preavviso.

Spesso, non dipende nemmeno dal nostro codice, ma da come utilizziamo librerie di terze parti.

Purtroppo in questi casi le tecniche precedenti spesso non bastano, dobbiamo usare la magia del try catch.

Come funziona il “Try-Catch”

Letteralmente, funziona così:

“Ok programmatore, provo ad eseguire il codice che hai messo dentro il try, ma se mi sale il nervoso ti sparo un’eccezione e poi son cavoli tuoi!”

In altre parole i passi da fare sono questi.

Non sei sicuro di una porzione di codice: la inserisci dentro al blocco “try”.

Subito dopo, inseriamo il catch e stampiamo a video il contenuto dell’eccezione.

Cos’è un’eccezione e che cos’è il catch

Sostanzialmente, se il codice contenuto nel blocco “try” non viene eseguito correttamente, l’esecuzione del programma termina.

Ma non ti lascia a bocca asciutta: ti genera un’eccezione, ovvero una variabile che contiene la lista di errori generati a fronte dell’esecuzione del blocco “try”:

try{
  Db.SQLQuery("Select * from Users");
}
catch (Exception excep){
  System.WriteLine("Errore in fase di esecuzione query "+excep.toString());
}

Carta e penna

“Grazie al c…!”

Delle volte è più potente di quanto sembri.

Spesso, capita anche ai migliori programmatori: sei talmente in preda al nervoso dato da un errore che continui a fissare il monitor senza trovare la luce, per poi trovarti in una situazione tipo:

“Ah, mancava un punto e virgola”.

Cosa fare allora?

Armarsi di carta e penna e scrivere una tabella:

Quella che vedi di fronte a te, è la famosa trace table.

Cos’è la trace table e come si usa

La trace table funziona in questo modo.

Isola la porzione di codice che ti sta facendo imbestialire.

Segnati tutte le variabili coinvolte e associa ad ognuna una colonna.

Numera le righe della porzione di codice: saranno le righe della tabella stessa.

Fai finta di eseguire la porzione di codice dall’inizio.

Scrivi dei valori arbitrari, oppure che abbiano senso per te, e associali alle variabili.

Esegui nella tua informaticoa altrimenti ad alta voce il codice: riga per riga.

Ogni volta che esegui una riga, scrivi sulla riga corrispondente della tabella il nuovo valore delle variabili coinvolte in quella riga.

Ripeti il processo fino all’ultima riga di codice.

In questo modo, non solo avrai una situazione più chiara, ma ti stacchi dal monitor vedendo il problema da una prospettiva diversa!

Questo è uno dei miei metodi preferiti.

L’ho sempre usato con largo successo con i miei studenti, ma il merito è della mia professoressa di informatica delle superiori: sia lodata la Professoressa Annunziata Rescigno 😀

Debug: una delle tecniche più strambe che esistono? Il rubber duck support

Chiudo l’articolo con una delle tecniche più insolite e assurde di sempre!

La sua storia e i motivi per cui viene utilizzata, è molto simile a quella della trace table.

Il rubber duck support, consiste nel prendere una paperella di gomma e immaginare che sia una persona in carne ed ossa.

Parti dal problema che stai riscontrando e spiegaglielo.

Spiegagli cosa ti aspetteresti faccia il tuo codice, esponi il tuo problema e cosa invece ti aspetteresti.

Perché funziona?

Esponendo il problema a qualcuno (o qualcosa in questo caso), ci permette di diventare più critici di fronte al problema stesso.

Commentandolo, esponendolo e spiegandolo, abbiamo modo di vederlo sotto una prospettiva diversa.

Ah giusto: funziona meglio se hai un collega al posto di una paperella di gomma 😉