Visual Studio Code Debugger: A Primer och Screencast

I tidigare inlägg har jag pratat lite om varför det är viktigt att använda en ordentlig debugger kontra några av PHPs inbyggda uttalanden. I förra inlägget går jag till och med igenom hur man ställer in Xdebug med Visual Studio Code (och MAMP Pro, om du använder).

Men om du aldrig har använt ett sådant här verktyg förut, du har aldrig sett hur det fungerar, eller du har aldrig sett varför det är så kraftfullt, jag vill ta upp det lite i det här inlägget.

Så jag kommer att gå igenom lite av att göra detta inom ramen för några definitioner och skärmdumpar samt en kort skärmsändning i slutet så att jag kan visa Visual Studio Code-debuggern som fungerar.

Visual Studio Code Debugger

Förutsatt att du har felsökaren installerad; det finns några termer som är värda att lära sig. Visst, det finns fler, men dessa är de som jag anser vara viktiga:

• Brytpunkter är där du säger åt programmet att stoppa dess körning. När koden har stannat vid det här laget kan du undersöka variabler, se vilka värden som är lagrade i minnet och så vidare.
• Klockor är variabler i koden som du bokstavligen vill titta på när de ändras under exekveringen av variabler.
• Start sätter igång felsökningen. Även om du har brytpunkter och klockor inställda, kommer debuggern inte att göra något förrän du startar den.
• Step Into är en åtgärd som, när du trycker på ett funktionsanrop, tar dig till funktionen som anropas. Ibland är detta användbart, som om du vill se vad funktionen gör; andra gånger är det onödigt om du bara bryr dig om att funktionen körs eller om du bara bryr dig om vad den returnerar.
• Steg över låter dig gå över en funktions exekvering så att exekveringen av programmet stoppas omedelbart efter att funktionen som du har klivit över har avslutats.
• Step Out används när du har klivit in i en funktion, träffat en punkt där du är klar med att utvärdera koden och sedan redo att gå tillbaka till där du hade ställt in en brytpunkt.
• Stop kommer att avsluta exekveringen av felsökaren.

Låter relativt tydligt, eller hur? Enligt min mening är det lättast att se detta i aktion.

Dessutom, för att se vilka ikoner som gör vad, är vanligtvis det bästa du kan göra att hålla muspekaren över dem och sedan läsa verktygstipsen; men efter en eller två av att ha använt dem kommer du att bli bekant med vad var och en gör.

När allt kommer omkring är ikonerna ganska beskrivande.

Ett exempel

Med det sagt, förutsatt att du har följt stegen i föregående artikel, här är ett kort exempel på hur du kan ställa in en brytpunkt och följa dess exekvering genom ett plugin.

1 Brytpunkt

Observera i bilden nedan att jag har placerat en brytpunkt bredvid en kodrad (som indikeras av den röda pricken).

Det är här körningen kommer att stoppa när jag startar felsökaren och börjar köra programmet.

2 Ställ in en klocka

Därefter betyder att titta på en variabel att vi vill se värdet av en variabel under programmets livscykel. Nedan lägger jag till en klocka till variabeln $description.

I nästa avsnitt kommer du att se värdet på klockan efter att programmet körts passerat den kodraden.

3 Utvärdera klockan

När koden har passerat den raden kan du se värdet på variabeln i  avsnittet Watch i felsökningsfönstret.

Observera i funktionen, det finns ett anrop till woocommerce_wp_text_input. Vi kommer att använda den här funktionen som ett exempel för att gå in i en funktion eftersom det är en funktion som är en del av WooCommerce-kärnan.

4 Förbered dig på att gå in

Innan du går in i en funktion är det viktigt att se till att funktionsnamnet är markerat.

När du är klar kommer du att kunna klicka på  knappen Step In för att se vad som händer i funktionen.

5 Kliv in

När du kliver in ser du kod som du inte skrev. Istället är det kod som är en del av WooCommerce (åtminstone i det här exemplet).

Baserat på din erfarenhet kommer du att se kod som du kanske skrev eller som någon annan skrev.

6 Kliv ut

När du har klivit ut ur koden, kommer du att återgå till kodraden direkt efter där du klev in i koden.

Vettigt?

En screencast

Och slutligen, här är en mycket kort screencast som går igenom hur allt ovanstående ser ut i aktion:

Som nämnts i videon är detta inte på något sätt heltäckande, men det borde vara tillräckligt för att visa hur kraftfull felsökning kan vara.

Det tar tid och övning

Felsökning tar lite mer tid än att dumpa variabler på skärmen.

Och jag säger inte att det inte har sin plats att göra det; Men om du vill få en djupare förståelse för vad som händer när du kör ditt program, eller om du vill utforska, säg, WordPress-kärnan, är det ett riktigt bra sätt att använda en debugger.

Dessutom skulle jag hävda att användning av en debugger kan hjälpa till att ge en större förståelse för vad som går fel (eller rätt) inom ramen för din kod så att du kan skapa den bästa möjliga lösningen för det.