Breakpoints i VS Code: slik feilsøker du kode uten å gjette

Hvis du noen gang har sittet og spammetconsole.logeller tilfeldige utskrifter for å finne en feil, er det på tide å ta i bruk breakpoints. De lar deg stoppe koden midt i kjøringen, se hva som faktisk skjer, og forstå logikken steg for steg.

I denne guiden ser vi på hvordan du kan bruke breakpoints i Visual Studio Code til å feilsøke rolig og systematisk, i stedet for å gjette deg fram. Eksemplene er enkle, men prinsippene er de samme uansett språk.

Hva er et breakpoint, egentlig?

Et breakpoint er et stoppunkt i koden din. Når programmet kjører og treffer linjen med breakpoint, pauser det. Da kan du se variabler, tilstand og kallstakk akkurat i det øyeblikket.

Forskjellen fra utskrift-baserte metoder er at du kan undersøke alt som er tilgjengelig i det scope’et: lokale variabler, parametere, globale verdier og returverdier, uten å endre koden din hver gang.

Kom i gang med breakpoints i VS Code

For å bruke breakpoints i VS Code trenger du to ting: en fungerende kjøringskonfigurasjon (Launch config) og en debugger for språket du jobber i. Mange språk støttes direkte gjennom offisielle eller populære utvidelser.

Når du har installert nødvendig utvidelse, gjør du som regel dette: åpne Debug-fanen, opprett en launch-konfigurasjon, og start debugging medF5. VS Code lager ofte et standardoppsett som holder for enkle prosjekter.

Slik setter du et enkelt breakpoint

For å sette et breakpoint klikker du i margen til venstre for linjenummeret. Det dukker opp en rød prikk. Når du kjører debugging, vil programmet stoppe der før den linjen kjører.

Test gjerne på en funksjon som du vet blir kalt, for eksempel i en løkke som går mange ganger, eller før en if-blokk der logikken ikke gjør det du forventer.

Stegvis kjøring: se logikken skje

Når koden har stoppet på et breakpoint, får du opp en liten verktøylinje øverst med knapper som ofte kalles Continue, Step Over, Step Into og Step Out. Disse er nøkkelen til å forstå flyten.

Step Overgår til neste linje i samme fil,Step Intohopper inn i funksjonskall, ogStep Outkjører ferdig nåværende funksjon og går tilbake til stedet den ble kalt fra. Ved å kombinere disse ser du nøyaktig rekkefølge i kjøringen.

Se og overvåk variabler

I debug-modus har du som regel enVariables-seksjon der du kan se lokale og globale verdier. Disse oppdateres for hver linje du går videre. Dette er ofte nok til å se hvorfor en betingelse slår feil ut.

Du kan også legge tilWatch expressions, altså egne små uttrykk du vil følge med på. Det kan være en spesifikk variabel, en egenskap på et objekt eller en enkel beregning du vil kontrollere underveis.

Conditionals: breakpoints som bare stopper når det gjelder

Noen ganger kjører en løkke hundrevis av ganger, men du bryr deg egentlig bare om én spesiell verdi. Da er det tungvint å trykke Step Over 200 ganger. Løsningen erbetingsede breakpoints.

Høyreklikk på et breakpoint og legg til en betingelse, for eksempel at en teller må være lik en gitt verdi. Programmet vil da bare stoppe når betingelsen er sann, og du slipper unødvendig stepping.

Logpoints: når du vil logge uten å endre koden

I stedet for å skrive midlertidige utskrifter i koden kan du brukelogpoints. De ligner på breakpoints, men stopper ikke programmet. De skriver bare en melding til debug-konsollen når linjen kjører.

Dette er nyttig når du vil følge med på flyt eller verdier i et miljø der du helst ikke vil endre filene hele tiden, for eksempel på delte prosjekter eller i mer følsom kode.

Typiske feil breakpoints hjelper deg å finne

Breakpoints er spesielt nyttige når du har logikk som virker riktig på papiret, men gir feil resultat. For eksempel en betingelse som aldri blir sann, eller en funksjon som returnerer noe annet enn du forventer.

De hjelper også når du har komplekse dataobjekter og ikke helt vet hvordan strukturen ser ut. Ved å stoppe koden der objektet blir opprettet eller endret, kan du utvide det i debug-panelet og se innholdet lag for lag.

Gode vaner når du jobber med breakpoints

En vanlig felle er å la gamle breakpoints ligge igjen. Da stopper koden senere på steder du har glemt, og du mister flyten. Gjør det til en vane å rydde opp breakpoints når du er ferdig med en feil.

En annen god vane er å gi deg selv et klart spørsmål før du starter debugging: Hva er det jeg vil finne ut nå? Da blir det lettere å plassere breakpoints på riktige linjer, og du slipper å gå deg bort i detaljer.

Hvorfor dette er bedre enn “print debugging”

Utskrifter kan fungere i enkle tilfeller, men skalerer dårlig når kodebasen vokser. Du glemmer ofte å fjerne midlertidige logger, de gjør koden rotete, og de gir deg bare øyeblikksbilder du måtte gjette deg fram til.

Med breakpoints er inspeksjon og flytkontroll skilt fra selve koden. Det gir renere filer, raskere feilsøking og en mer systematisk forståelse av hvordan programmet faktisk kjører.

Neste steg: øv på et lite prosjekt

Den raskeste måten å bli komfortabel med breakpoints på er å ta et lite, kjent prosjekt og med vilje introdusere en feil. Sett deg så som mål å finne feilen kun ved hjelp av breakpoints, stepping og variabelinspeksjon.

Jo tidligere du gjør dette til en del av din daglige arbeidsflyt, desto mindre tid vil du senere bruke på frustrerende feilsøking og tilfeldige gjetninger.