Als je tijdens het programmeren niet de resultaten krijgt die je zou willen, of je krijgt foutmeldingen, dan is gefrustreerd naar je code staren wel begrijpelijk, maar meestal niet zo zinvol.

Wat doe je dan wel, als de compiler foutmeldingen geeft of erger, als bij de uitvoering van je programma foutmeldingen komen die je niet zelf geprogrammeerd hebt? Of je krijgt geen foutmelding, maar gewoon andere resultaten dan verwacht. Natuurlijk ga je op den duur foutmeldingen wel een beetje begrijpen en dan ook direct opvolgen. Vooral meldingen van de compiler zijn vaak prima direct te snappen. Maar wat dan?

Een eerste stap kan zijn om je code stap voor stap na te lopen en je goed te realiseren wat de computer exact doet bij ieder commando, iedere functie. Computers doen niks fout, ze doen wat jij in je programma hebt geschreven. Dus wat is dat precies?

Voor alles ingewikkelder dan de simpelste code, gaat dit al snel niet genoeg zijn. Bij iets complexere code kan ChatGPT helpen. Voer simpelweg je hele code aan ChatGPT en goede kans dat je direct aanwijzingen krijgt over wat je fout hebt gedaan. Is het daarmee opgelost, dan is dat mooi. Maar ChatGPT kan niet alles voor je oplossen en maakt zelf ook fouten. Dus je zal op enig moment een stap verder moeten gaan.

In de praktijk werkt het vaak goed om op punten in je programma waar belangrijke wijzigingen plaatsvinden breakpoints in te voegen. Gewoon een stukje programma dat de waarde van relevante variabelen op het scherm zet en even pauzeert, zodat je die kan bestuderen. Zodra je een punt bereikt waar de data niet klopt weet je tenminste waar je ongeveer moet zoeken. Dringend advies: nummer die breakpoints. Als je dan oplet, zal je zien dat sommige breakpoints nooit worden bereikt. Dat is een aanwijzing dat je het bij een if(), een while() of dergelijke functies moet zoeken. Je breakpoint wordt nooit bereikt? Waarschijnlijk zit er daarvoor dan een conditie waarvan je dacht dat die positief moest zijn, maar die altijd negatief blijft.

Is dat alles nog niet genoeg, dan is het tijd voor het zware geschut: een debugger. Een bug is een programma- of computerfout, dus een debugger is een programma om jouw programma mee te ontdoen van bugs. Een populaire, makkelijke, gratis debugger is gdb. Als je Pi OS gebruikt heb je gdb al, bij andere systemen zal je wellicht nog moeten installeren.

Om gdb te gebruiken, moet je je programma compileren met de optie -g. Stel dat je broncode programma.c is dan zou je kunnen compileren met gcc -g programma.c -o programma

Dat levert een normaal werkend programma op, maar wel een stuk groter. Die extra omvang komt doordat allerlei informatie is toegevoegd die de debugger kan gebruiken. Debuggen doe je nu met gdb programma of, als je een voldoende nieuwe versie van gdb hebt een aanrader: gdb -tui programma.

In de TUI-versie kan je nu met het commando layout next een scherm-layout krijgen waarop je de sourcecode die je schreef, eventueel de gecompileerde assembler-code, en je werkscherm onder elkaar krijgt. Met run voer je je programma uit en krijg je informatie als het fout gaat. Maar veel mooier is als je een breakpoint zet, met het commando break. Dat kan op een regelnummer in je code, of bijvoorbeeld op een functie. In ieder C programma zit de functie main(), dus met break main zet je een breakpoint op het hoofdprogramma. Daar stopt de uitvoering van je code en je kan nu stap voor stap door je code gaan met next, in een aantal variaties (lees echt de handleiding uit de link hiervoor!). Als je op enig moment wil weten wat de waarde van een variabele is, dan kan je die uitlezen met het commentator print variabele.

Wat je hiermee hebt bereikt is een veel geavanceerdere versie van de zelf geprogrammeerde breakpoints die ik hiervoor noemde. Voor wie echt diep wil gaan, is het volgen van de gecompileerde assemblercode helemaal mooi. Maar als je alleen al gebruikmaakt van de combinatie van next en print, in de layout src, zal je merken dat je fantastisch inzicht krijgt in wat je programma precies aan het doen is en waarom dat foutmeldingen of onverwachte resultaten oplevert. Probeer het echt uit!

Wie mee wil doen met #klooienmetcomputers kan dat doen via GitHub. Maak een account op www.github.com en zoek naar Abmvk/kmc. Het account Abmvk volgen kan ook. Lezers zijn vrij te gebruiken wat ze willen en om zelf zaken toe te voegen of aan te passen, vragen te stellen of commentaar te leveren.