Strategier til fejlsøgning

Når man er i gang med at lære et nyt sprog, er det uundgåeligt, at man fra tid til anden skriver et ord forkert eller ikke har helt styr på syntaksen. Det er helt normalt, at man løber ind i vanskeligheder, når man lærer at programmere. Det skyldes, at computere - uanset hvor smarte de er - har endog meget svært ved at forstå vores instruktioner. De seneste års fremgang inden for kunstig intelligens og store sprogmodeller implementeret i chatbots kan måske få computeren til at virke intelligent og forstående, selv når vi ikke formulerer os helt klart. Men faktisk har computere i programmeringssammenhæng brug for, at vi følger nogle klare regler om et forudbestemt ordforråd. De kræver også, at vi følger en entydig syntaks til punkt og prikke. Ellers giver de op og giver os en fejlmeddelelse. Og det sker jævnligt, også for erfarne programmører. Derfor er det vigtigt, at du etablerer nogle gode strategier til fejlsøgning: Det vil både være nyttigt i forhold til at løse de problemer, du måtte løbe ind i, men det vil også give adgang til en bredere viden og teknisk forståelse. En fejlmeddelelse er måske ikke lige det sjoveste, vi kan opleve, men den udgør ofte en lejlighed til at lære noget nyt.

Sådan håndterer du kode, der ikke virker

Øv - din kode virker ikke. Enten kommer der slet ingen lyd, når du kører din kode, eller også sker der ikke det, du forventer. Du har nu siddet den sidste halve time og prøvet at finde fejlen. Du har genstartet SuperCollider og din computer, men desværre uden held. Hvad gør man så?

Læs fejlmeddelelsen

Hvis der dukker en fejlmeddelelse eller anden relevant information op i SuperColliders post window, er dette det første sted, du bør kigge. SuperColliders fejlmeddelelser er ikke altid lige informative, men ofte giver de et hint til hvad der er på færde. Fejlmeddelelsen vil være fremhævet med en særlig tekstfarve, men nogle gange er det nødvendigt at scrolle op i SuperColliders post window for at finde den.

Tjek de mest typiske fejlkilder

Der findes nogle fejl, som jeg ser igen og igen hos studerende. Og indrømmet, de sniger sig lejlighedsvis også ind i kildekode, jeg selv skriver. Så tjek først, om det kan være et af disse problemer, du står med.

Parenteser og klammer: Er alle dine parenteser og klammer, dvs. (), {} og [], men også omkransende tegn som \**\, '' og "" startet og afsluttet korrekt?
Virker Ctrl/Cmd-Enter ikke?: Dette skyldes rod i parenteserne. Se om du kan finde en manglende parentes et sted. Prøv at flytte en lille del af din kode over i et nyt dokument for at tjekke, om den del virker. Gentag dette, indtil du finder fejlen.
Komma/punktum/kolon/semikolon: Er følgende tegn anvendt korrekt? , . : ;
Stort/småt begyndelsesbogstav: Klassenavne som Pbind og Saw skal have stort begyndelsesbogstav. Methods og variabler som .play og ~minVariabel har altid små begyndelsesbogstaver.
Hvis du ikke hører noget lyd: Er lydserveren bootet? - Dette tjekker du ved at se om rækken af tal nederst til højre er grønne (så er serveren bootet) eller grå (serveren er ikke bootet). Brug evt. den lidt morbide kommando Server.killAll; for at slukke alle serverprocesser, før du genstarter serveren.

Simplificér din kildekode og isolér problemet

Det er altid fornuftigt at forenkle kildekoden så meget som muligt. Det gør det lettere at gennemskue intentionen med kildekoden samt hvor fejlen kan have sneget sig ind.

Del kildekoden op: Prøv at flytte det stykke kildekode, du arbejder på, over i et nyt dokument. Hvis du har syntaksfejl i dele af dit dokument, kan det påvirke resten af dokumentet.
Deaktiver dele af kildekoden: Prøv at deaktivere dele af din kode (med // eller /**/) og eksekvere igen for at finde den del af koden, som er årsag til problemerne.
Sammenlign din kildekode med et fungerende eksempel: Find et lignende eksempel fra undervisningsmateriale eller SuperColliders dokumentation, som virker. Kan du få øje på nogle forskelle på din kode og det valgte eksempel?
Start forfra med afsæt i et fungerende eksempel: Start forfra i et nyt dokument med et simpelt eksempel fra denne bog eller andre lødige ressourcer, hvor koden fungerer som forventet. Øg kompleksiteten derfra og eksekvér koden så ofte som muligt. På den måde kan du identificere hvor problemet opstår.

Tal med en gummiand

Det lyder måske lidt skørt, men der findes faktisk en udbredt debugging-strategi, som kaldes rubber duck debugging. Strategien går ud på, at man (til en reel eller metaforisk gummiand) forklarer, hvad man forventer, at kildekoden gør. Det er vigtigt, at man forklarer kildekoden trin for trin, samt at man beskriver det uventede, der sker. At beskrive processen og problemet på denne måde kan give aha-oplevelser og få selv de mest garvede programmører til at få øje på det, de ellers havde stirret sig blinde på (Hunt, 2000, p. 95)¹. Dette kan rent læringsmæssigt betragtes som en form for problemanalyse, der gennem verbalisering giver mulighed for ny indsigt.

En nyere variant af denne strategi kunne være at konferere med en sprogmodel (chatbot). Moderne chatbots kan i nogle tilfælde (men bestemt ikke altid) spotte syntaksfejl eller andre problemer, som vi selv har stirret os blinde på. OBS: Hvis du er studerende, bør du være opmærksom på, om brug af kunstig intelligens til fejlsøgning er tilladt på din uddannelse. Spørg din underviser eller studievejleder, hvis du er i tvivl.

Søg information om problemet

Du kan altid konsultere SuperColliders indbyggede dokumentation. Der kan du søge på nøgleord, klassenavne, methods osv. Du kan også slå konkrete klasser eller methods op, hvis du placerer din cursor ved fx klassenavnet og trykker Ctrl/Cmd-D. Så vil SuperCollider slå den markerede klasse eller method op for dig. Det kan være utroligt handy, hvis man fx ikke kan huske hvad argumenterne til en bestemt method går ud på.

Derudover findes der selvfølgelig søgemaskiner og sociale fora online, som kan være udmærkede kilder til at lære af andre brugeres udvekslinger og erfaringer. Søg på de nøgleord, der har med dit problem at gøre, og måske kan du være heldig, at andre har oplevet det samme og løst problemet.

Spørg om hjælp

Der findes mange mennesker, der gerne vil hjælpe - især hvis man spørger på en konstruktiv og ordentlig måde. Spørg hellere en gang for meget end en gang for lidt!

Når du spørger din underviser om hjælp vedrørende musik- og lydprogrammering, er det altid en god ide at vedlægge følgende.

Et minimalt eksempel på den kildekode, som ikke giver det forventede resultat. Hvis man ikke kan se kildekoden, er det næsten altid umuligt at hjælpe.
En beskrivelse af problemet: Hvad forventer du, og hvordan afviger resultatet fra det forventede?
En beskrivelse af fejlsøgningen: Hvad har du allerede selv prøvet for at løse problemet?

Hvis disse oplysninger er med, giver du modparten rigtig gode forudsætninger for at komme med et brugbart svar.

Det er helt normalt og forventeligt, at nybegyndere inden for programmering løber ind i syntaksfejl og andre vanskeligheder. Men hvis du bliver god til fejlsøgning, bliver det hurtigt en fornøjelse at løse problemerne.

Hunt, A. (2000). The pragmatic programmer: From journeyman to master. Reading, Mass. : Addison-Wesley. http://archive.org/details/isbn\_9780201616224 ↩