Lesbar kode i praksis: en enkel sjekkliste som gjør deg til en bedre utvikler

God lesbarhet er kanskje den viktigste, men minst glamorøse delen av programmering. Likevel er det ofte dette som avgjør om du klarer å videreutvikle et prosjekt uten frustrasjon og feil.

I denne artikkelen får du en konkret og jordnær sjekkliste for mer lesbar kode, med små grep du kan ta i bruk allerede i dag, uansett språk og erfaringsnivå.

Hva betyr egentlig lesbar kode?

Lesbar kode er kode som en annen utvikler (inkludert deg selv om seks måneder) raskt kan forstå, endre og feilsøke uten å måtte gjette. Det handler ikke bare om stil, men om hvor lett det er å se hensikten bak det som skjer.

En god tommelfingerregel: Hvis du må forklare koden muntlig for at den skal gi mening, kan den ofte forbedres slik at forklaringen ligger i selve strukturen og navngivingen.

1. Gi variabler og funksjoner tydelige navn

Navn er kanskje det mest undervurderte verktøyet du har. Dårlige navn gjør at alt annet virker vanskelig, mens gode navn kan fjerne behovet for flere kommentarer og dokumentasjon.

Unngå forkortelser som bare du skjønner, og prøv å skrive navn som forklarer hva noe er, eller hva det gjør, uten ekstra forklaringer.

Praktiske navnetips

• Beskriv hensikt, ikke type: SkrivtotalBelopi stedet forint1ellermyVar.
• Bruk samme ord konsekvent: Hvis du velgerkunde, bruk det overalt i stedet for å variere mellomkunde,klientogbruker.
• Navngi funksjoner som handlinger: Funksjoner gjør noe, så bruk verb somberegnPris(),hentKunde()oglagreBestilling().

Spør deg selv: Hvis en ny utvikler åpner filen for første gang, kan de gjette hva variabler og funksjoner betyr bare ut fra navnene?

2. Del opp logikk i små, tydelige biter

En vanlig årsak til ulesbar kode er for store funksjoner der “alt” skjer samtidig. Det gjør feilsøking vanskelig, og logikken blir lett blandet sammen.

En enkel forbedring er å bryte ned koden i mindre funksjoner, der hver del gjør én ting tydelig og kan forklares med én kort setning.

En nyttig tommelfingerregel

Hvis du ikke klarer å oppsummere hva en funksjon gjør i én setning uten å bruke ordet “og”, gjør den sannsynligvis for mye. Da kan du ofte splitte den opp i to eller flere funksjoner.

Dette gir flere fordeler: lettere testing, færre skjulte bivirkninger og enklere gjenbruk i andre deler av prosjektet.

3. Gruppér relatert logikk og fjern støy

Strukturen i filene dine påvirker hvor raskt du finner igjen ting. Når logikk av samme type ligger samlet, kan du enklere se helheten og oppdage feil eller forbedringsmuligheter.

Prøv å plassere funksjoner som hører sammen i nærheten av hverandre, og unngå å blande helt ulike ansvarsområder i samme fil hvis du kan dele dem opp.

Rydding som forbedrer lesbarheten

• Fjern ubrukte variabler og gamle funksjoner som ikke lenger er i bruk.
• Samle hjelpefunksjoner nederst i filen eller i en egen modul.
• Hold konfigurasjon, konstanter og “magiske tall” samlet og tydelig navngitt.

Ofte føles dette som små kosmetiske endringer, men sammen gjør de det mye enklere å tenke klart når du leser logikken.

4. Skriv kommentarer som forklarer hvorfor, ikke hva

Mange enten overkommenterer alt, eller skriver nesten ingen kommentarer. Et nyttig mål er å kommentere minst mulig, men akkurat nok til at vanskelige valg og antakelser blir forståelige.

Komentarer bør først og fremst forklarehvorfornoe er gjort på en bestemt måte, ikke bare beskrive hva koden åpenbart gjør linje for linje.

Gode vs. dårlige kommentarer

• Dårlig: // øk teller med 1 rett over teller++; (det er allerede åpenbart).
• Bedre: // vi starter på 1 i stedet for 0 fordi eksternt API forventer 1-basert indeks.

Hvis du ofte føler behov for å kommentere hva en blokk gjør, kan det være et tegn på at den bør flyttes inn i en egen funksjon med et godt navn.

5. Velg én stil og vær konsekvent

Små stilforskjeller virker kanskje ubetydelige, men når de blandes over tid, blir koden tung å lese. Konsekvens gjør at hjernen kan “slappe av” og fokusere på logikken i stedet for form.

Det viktigste er ikke hvilken bestemt stil du velger, men at du og eventuelt teamet ditt følger den samme stilen overalt.

En enkel stil-sjekkliste

• Enighet om innrykk (for eksempel 2 eller 4 mellomrom).
• Fast måte å navngi filer og mapper på.
• Konsekvent bruk av store og små bokstaver i navn.
• Lik form på funksjonsdefinisjoner og struktur i kontrollflyt.

Mange språk har verktøy for automatisk formatering. Slike verktøy fjerner diskusjoner om stil og gjør det enklere å holde strukturen ryddig over tid.

6. Tenk på leseren når du skriver kode

Lesbar kode handler til syvende og sist om respekt for neste person som skal jobbe med prosjektet. Ofte er denne personen deg selv om noen uker eller måneder, når all kontekst er glemt.

Prøv å se på funksjoner, variabler og strukturer med “ferske øyne”: Hadde dette gitt mening for meg om jeg åpnet filen for første gang i dag, eller måtte jeg ha satt meg inn i alt rundt før det ble tydelig?

En liten rutine du kan starte med i dag

Før du avslutter en økt med utvikling, sett av fem minutter til ren lesbarhet: gi nye navn der det trengs, del opp én for lang funksjon og fjern åpenbar støy. Disse små justeringene akkumuleres fort til en stor forskjell.

Over tid merker du at det blir raskere å feilsøke, enklere å forklare strukturen til andre, og mindre skummelt å gjøre endringer i eksisterende logikk.