Visual Studio Code Debugger: Primer e Screencast

Nei post precedenti, ho parlato un po’ del motivo per cui l’utilizzo di un debugger adeguato rispetto ad alcune delle istruzioni integrate di PHP è importante. Nell’ultimo post, inoltre, spiego come configurare Xdebug con Visual Studio Code (e MAMP Pro, se stai utilizzando).

Ma se non hai mai usato uno strumento come questo prima, non hai mai visto come funziona, o non hai mai visto perché è così potente, voglio parlarne un po’ in questo post.

Quindi esaminerò un po’ questa operazione nel contesto di alcune definizioni e schermate, nonché un breve screencast alla fine in modo da poter mostrare il debugger di Visual Studio Code che funziona in azione.

Il debugger di codice di Visual Studio

Supponendo che tu abbia installato il debugger; ci sono alcuni termini che vale la pena imparare. Certo, ce ne sono altri, ma questi sono quelli che considero fondamentali:

• I punti di interruzione sono dove stai dicendo al programma di interrompere la sua esecuzione. Una volta che il codice si è fermato a questo punto, puoi esaminare le variabili, vedere quali valori sono archiviati in memoria e così via.
• Gli orologi sono variabili nel codice che vuoi letteralmente guardare mentre cambiano durante l’esecuzione delle variabili.
• Start mette in moto il debugger. Anche se hai impostato punti di interruzione e controlli, il debugger non farà nulla finché non lo avvii.
• Step Into è un’azione che, quando si esegue una chiamata di funzione, ti porterà nella funzione che viene invocata. A volte questo è utile, ad esempio se vuoi vedere cosa sta facendo la funzione; altre volte, non è necessario se ti interessa solo la funzione in esecuzione o ti interessa solo ciò che restituisce.
• Step Over ti consentirà di scavalcare l’esecuzione di una funzione in modo tale che l’esecuzione del programma si interrompa immediatamente dopo che la funzione che hai scavalcato è terminata.
• Esci viene utilizzato quando sei entrato in una funzione, raggiungi un punto in cui hai finito di valutare il codice e quindi sei pronto per tornare al punto in cui avevi impostato un punto di interruzione.
• Stop interromperà l’esecuzione del debugger.

Suona relativamente chiaro, vero? Secondo me, è più facile vederlo in azione.

Inoltre, per vedere quali icone fanno cosa, di solito la cosa migliore da fare è passare il mouse sopra di esse e poi leggere i suggerimenti; tuttavia, dopo un tempo o due di utilizzo, acquisirai familiarità con ciò che ciascuno fa.

Dopotutto, le icone sono piuttosto descrittive.

Un esempio

Detto questo, supponendo che tu abbia seguito i passaggi nell’articolo precedente, ecco un breve esempio su come impostare un punto di interruzione e seguirne l’esecuzione tramite un plug-in.

1 punto di interruzione

Nota nell’immagine qui sotto, ho posizionato un punto di interruzione accanto a una riga di codice (come indicato dal punto rosso).

È qui che l’esecuzione si fermerà una volta avviato il debugger e iniziato l’esecuzione del programma.

2 Impostare un orologio

Quindi, guardare una variabile significa che vogliamo vedere il valore di una variabile durante tutto il ciclo di vita del programma. Di seguito, aggiungo un orologio alla variabile $ description.

Nella sezione successiva, vedrai il valore dell’orologio dopo che l’esecuzione del programma ha superato quella riga di codice.

3 Valuta l’orologio

Una volta che il codice ha superato quella riga, puoi vedere il valore della variabile nella  sezione Watch del riquadro di debug.

Avviso nella funzione, c’è una chiamata a woocommerce_wp_text_input. Useremo questa funzione come esempio per entrare in una funzione poiché è una funzione che fa parte del core di WooCommerce.

4 Preparati a intervenire

Prima di entrare in una funzione, è importante assicurarsi che il nome della funzione sia evidenziato.

Una volta terminato, potrai fare clic sul pulsante Entra per vedere cosa sta succedendo nella funzione.

5 Entra

Dopo essere entrato, vedrai il codice che non hai scritto. Invece, è il codice che fa parte di WooCommerce (almeno in questo esempio).

In base alla tua esperienza, vedrai il codice che forse hai scritto tu o che qualcun altro ha scritto.

6 Esci

Una volta uscito dal codice, tornerai alla riga di codice immediatamente dopo essere entrato nel codice.

Ha senso?

Uno Screencast

E infine, ecco un brevissimo screencast che illustra come appare tutto quanto sopra in azione:

Come accennato nel video, questo non è affatto completo, ma dovrebbe essere sufficiente per mostrare quanto può essere potente il debug.

Ci vuole tempo e pratica

Il debug richiede un po’ più di tempo rispetto al dump delle variabili sullo schermo.

E non sto dicendo che fare questo non abbia il suo posto; tuttavia, se vuoi ottenere una comprensione più profonda di cosa sta succedendo ogni volta che esegui il tuo programma, o se vuoi esplorare, ad esempio, il core di WordPress, usare un debugger è davvero un buon modo per farlo.

Inoltre, direi che l’utilizzo di un debugger può aiutare a comprendere meglio cosa sta andando storto (o giusto) nel contesto del codice in modo da poter creare la migliore soluzione possibile per esso.