Pseudokode kan være det sværeste programmeringssprog at mestre

pseudokode
Mennesker er ikke computere. Derfor kan det være en god idé at give slip på præcisionen for at kunne kommunikere med andre mennesker om strukturen af et kodeforslag.

Hvor præcis skal man være, når man lige skal omsætte sine løse idéer til noget, der kan blive til konkret kode? Når man står ved whiteboardet og skal skitsere en funktion for en kollega, eller skrive en note til sig selv om, hvordan man lige skal håndtere de der delstrenge, så kan det være nyttigt at skrive en kode-kladde, men det er ikke altid let.

Pseudokode er redskab, som kan hjælpe med at få styr på den overordnede kodestruktur, men udfordringen er at skrive kode uden at skrive rigtig kode. Målet med pseudokode er blot at skrive en simpel udgave af programmet hurtigt - ikke at skrive kode, som kan kompileres.

Der findes etablerede metoder til at skrive pseudokode, men det kan også virke lidt underligt at skrive i en mere klassisk Fortran- eller Basic-stil, hvis man normalt koder i Java eller C#, og så ender du måske lige som jeg med en underlig blanding.

function HelloWorld
  print in console: "Hello World!"
end

Jeg har svært ved at give slip og bare skrive pseudokode uden de rigtige tuborgklammer, semikoloner, variabelnavne og metodekald. Så denne guide er også til mig selv.

For selvom jeg har svært ved skrive pseudokode uden at gå for meget i detaljer, så har jeg gennem årene opbygget en række værktøjer til at gøre noget lignende til at skrive tekster, som også kan anvendes på kode.

Læg dine sædvanlige værktøjer væk

Pseudokoden skal bare være noget, der giver en idé om, hvordan programmet skal fungere. Det skal være præcist nok til, at en kollega kan samle dine noter op og forstå meningen, men du behøver ikke korrekt syntaks. Og ud over den helt basale logik (IF, THEN, ELSE, WHILE, FOR, CASE og så videre), så kan det være en fordel at skrive i et mere naturligt sprog.

Det er lettere at gøre, hvis man ikke sidder med sin kodeeditor, som sætter røde streger under ugyldig syntaks og gør det lidt for let - men ikke let nok - at få forslag til metodekald til standardklasser i API'et.

Skriv i stedet i Word, hvor al din kode får røde streger, eller skriv på et stykke papir eller et whiteboard. Her er det vigtigste at vælge et medium, som passer til arbejdssituationen. Er din pseudokode bare lige en note til dit eget brug, som du skal bruge med det samme, så er et stykke papir godt. Skal du arbejde sammen med andre, så er whiteboardet måske bedst.

Men hvis pseudokoden skal kunne holde sig i et stykke tid, så skriv det i elektronisk form.

Kombinér også gerne flere medier. Brug papiret til at lave en disposition eller forsøge med de første skitser, og skriv så en elektronisk udgave bagefter, hvis det er nødvendigt. Jeg gør det samme, hvis jeg skal skrive en længere artikel og har brug for en disposition.

Disponér først

Og netop en disposition er en god idé - også til kode. Med pseudokode har du god mulighed for at arbejde udefra og ind. At gå fra en overordnet struktur til det specifikke, og du kan selv vælge, hvor detaljeret de enkelte dele skal være.

Igen er det vigtigt, at den primære opgave med pseudokode er at få et overblik til at skrive den konkrete kode. Jeg har selv svært ved ikke at snyde, men prøver at holde detaljerne til nogle helt centrale dele, hvor jeg eksempelvis har researchet mig frem til noget, hvor det er en fordel at skrive det præcist ned med det samme.

Her kan man indvende, at det nok er bedre - lidt omvendt af normal kodning - er bedre at placere den præcise løsning i en kommentar eller note, og så holde fast i den løse pseudokode for at bevare overblikket.

Det er altså ideelt set bedre at udelade det korrekte regex-udtryk for i stedet at beskrive, hvad udtrykket skal gøre i pseudokoden.

Vær ikke bange for at springe rundt

Det er vigtigt at huske, hvad pseudokode skal bruges til. Det er værktøj, der skal hjælpe dig med at få greb om løsningen til det problem, din færdige kode skal løse.

Min hjerne bliver let distraheret, men det er ok, når opgaven er at disponere og få en overordnet struktur på plads. Hvis idéen til at håndtere events kommer, mens jeg er ved at skrive pseudokoden til min parsing-løkke, så tager det ikke lang tid at skrive event-idéen ned.

Pseudokode skal kunne skrives hurtigt, og meningen er at få en rå kladde, som i sidste ende gør det færdige produkt bedre.

Derfor er det i orden at have ufærdige dele liggende spredt rundt omkring, hvis det er sådan, man arbejder bedst. Den metodiske gennemgang, hvor delelementer kan krydses af, når de er klar, kommer først i spil bagefter.

Slet og dræb dine egne idéer

Det er et velkendt princip, at det er billigst at erkende og rette sine fejl tidligt i processen. En del af formålet med at skrive pseudokode på en måde, der er tilstrækkelig præcis til, at du ved, hvad koden skal gøre, men ikke præcis nok til at være praktisk anvendelig kode, er mulighed for at slå fejl ihjel tidligt.

Har du skrevet 50 linjer ægte kode og opdager, at det var ikke den rigtige løsning, så kan det være svært bare at slette det. Hvis du i stedet har skrevet 25 linjer på et stykke papir, så er det lettere at slette det, fordi du alligevel manglede at overføre det til færdig kode i editoren.

Tilsvarende kan pseudokode også hjælpe dig med at finde ud af, om noget færdig kode, der volder dig problemer, i virkeligheden skulle slettes og erstattes af en ny løsning. Det koster meget lidt at afprøve et par nye idéer på papir for at se, om de er bedre.

Og ligesom en gummiand være en nyttig partner at tale med om sin kode, så kan papiret også være det. Jeg har altid en blok med ternet papir liggende på bordet inden for rækkevidde, som kan bruges til alt fra skitser og noter til pseudokode.

Pseudokode er også dokumentation

En mental fordel ved at skrive pseudokode er, at du får vendt problemet og formuleret løsningen. Jeg foretrækker at kombinere pseudokode med noter til mig selv, hvor jeg forklarer mine overvejelser til mit fremtidige selv.

Mit nutids-jeg og mit fremtids-jeg er ikke altid lige gode venner. Eller rettere: Når mit fremtids-jeg er blevet til mit nutids-jeg, så er mit nye nutids-jeg ikke altid helt tilfreds med mit fortids-jegs arbejde.

Derfor hjælper det at dokumentere sin tankeproces, og det gør du, når du skriver pseudokode - i hvert fald hvis du bruger den lidt bredere definition, hvor forklarende sprog er en central ingrediens.

Din pseudokode kan også være nyttig at have i baghånden, hvis du på et tidspunkt skal forklare en person, der ikke lige har arbejdet på det samme projekt eller måske slet ikke er programmør, hvad din kode gør.

Begræns dig

Pseudokodes største styrke er til algoritmer - vel at mærke forstået mere bredt end eksempelvis en sorteringsalgoritme. Nøgleingredienserne er løkker og betingelser, som sættes sammen, ligesom pseudokode kan give dig overblik over nødvendige variable.

Jeg foretrækker også at inkludere typer i min pseudokode, men det kan være en smagssag. Om ikke andet kan det være en god idé at notere sig typevalg i noterne, hvor det kan være nyttigt.

Din pseudokode bør ikke være mere end det absolut mest nødvendige. Ud over at droppe alle specifikke detaljer om implementering i færdig kode, så bør pseudokoden handle om programmets logik.

Ting som relationer mellem komponenter, klassediagrammer og andet, der specificerer eksempelvis et flow gennem programmet - det er der bedre værktøjer til. Lad være med at prøve at bruge pseudokode til at beskrive noget, hvor UML ville være bedre.

Det handler om kommunikation

Pseudokode er et kommunikationsværktøj mellem mennesker. Det er en abstraktion, ligesom de fleste programmeringssprog er en abstraktion til at kommunikere mellem menneske og computer.

Du kan bruge pseudokode til at kommunikere med dig selv eller med kollegaer, men igen er det vigtigt, at opgaven ikke er færdig kode, men at afprøve og strukturere idéer.

Derfor bør du også ignorere alle udråb om, at noget ikke er rigtig pseudokode - for når man læser udtrykket 'rigtig pseudokode', så burde den indbyggede selvmodsigelse være åbenlys. Om du vil skrive din pseudokode inspireret af C eller Basic er underordnet. Det vigtige er forståelsen.

Din pseudokode skal så at sige afspejle, hvordan du tænker programmets struktur. Selv er jeg ikke stor fan af meget kompakt kode, men foretrækker hellere en linje for meget. Det afspejler måske, at jeg som journalist skal tænke på, at andre skal læse min tekst, og ligesom mindre erfarne læsere skal kunne følge med, så foretrækker jeg, at min kode ikke kræver, at læseren - som også kan være fremtids-mig - kan genkende en bestemt kompakt skriveform i det pågældende programmeringssprog.

Her er pseudokode en god øvelse, fordi du skal forklare, hvad din kode gør. Og ideelt set bør din færdige kode også gøre forklare læseren, hvad den gør. Compileren skal nok klare det med at oversætte den til noget effektivt.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Følg forløbet

Kommentarer (6)

Kommentarer (6)
Klavs Klavsen

Jeg plejer at skrive det i et naturligt sprog - som kommentarer..

#indlæs liste af filer  
#loop over liste og   
# - check hver fil for corrent content-type - og øg tæller for hit  
# - check hver fil for "bla bla" - og øg tæller for hit  
#  
# skriv tæller sum

Så kan jeg nemlig bare skrive koden under hver #kommentar.. og jeg opdager som en del af min "pseudokode" - normalt hvis jeg skal ændre rækkefølgen på ting, eller at jeg mangler noget information for at kunne udføre et skridt.
Det hjælper mig til at holde styr på opgaven :)

Anders Reinhardt Hansen

Din ovenstående er alt for præcis. Hvis din udvikler ikke selv kan skrive en bubble sort bør du måske konsultere en anden udvikler. Du skal som hjælper ikke beskrive den kode der skal skrives, men den måde koden skal agere på det input den får. Med andre ord en slags high level unittest. Dernæst skal du have en fornuftig review process​ der validere den skrevne kode, og måske en fornuftig proces omkring hvad der skal ske når der er tvivl om hvad du mener med din kode.

Per Erik Rønne

Personligt skriver jeg nu pseudokode i et pseudopascal, der er en passende udvidet udgave af det pascal, jeg på datalogistudiet lærte som første programmeringssprog.

Skal jeg derfor beskrive en heuristik hvori indgår mængder af mængder, gør jeg det ved at beskrive den på følgende algoritmiske måde:

for each <item 1> in <set>
begin
for each <item 2> in <item 1>
begin
...
end
end

  • hvor <item 1> i sig selv er en mængde.

Og så kan man altid bruge beskrivende procedurenavne ... mens der skøjtes hen over detaljerne.

Log ind eller opret en konto for at skrive kommentarer

Pressemeddelelser

Affecto Denmark reaches highest Microsoft Partner level

Affecto Denmark, a leading provider of data-driven solutions, has reached the highest level in the Microsoft partner ecosystem: Managed Partner.
22. jun 2017

Innovate your business with Affecto's IoT Explorer Kit

Are you unsure if Internet of Things fits your business strategy?
31. maj 2017

Big Data Lake Summit: Fast and Trusted Insights

If you want to outpace, outsmart and outperform your competition in a digital world, you need trusted data that can be turned into actionable business insights at speed.
24. apr 2017