Clean Code: Skriv kode som er en glede å lese

Hva er clean code og hvorfor er det viktig?

Clean code er kode som er lett å lese, forstå og endre. Robert C. Martin (kjent som "Uncle Bob") argumenterer i sin klassiske bok at kode skrives én gang, men leses titalls og hundretalls ganger – av deg selv, av kollegaer og av fremtidige vedlikeholdere. Kode er kommunikasjon, og clean code kommuniserer intensjonen tydelig.

For norske utviklingsteam er clean code spesielt relevant fordi turnover i tech-bransjen er høy og kodebasen er et langsiktig felles aktivum. Ryddige kodebaser er raskere å sette seg inn i, billigere å vedlikeholde og mer motiverende å jobbe med. "Clean code does one thing well", siterer Bjarne Stroustrup i bokens åpning.

Navngivning: Den viktigste ferdigheten

Gode navn er den enkeltfaktoren som har størst effekt på kodelesbarhet. Et godt navn avslører hensikten uten kommentarer, skiller mellom konsepter og unngår desinformasjon. Dårlige navn – `d`, `data`, `temp`, `manager` – tvinger leseren til å holde mye kontekst i hodet og gjøre mer mentalt arbeid enn nødvendig.

Clean code-reglene for navngivning er enkle men kraftfulle: bruk beskrivende navn som avslører hensikten (`numberOfDaysUntilDeadline` i stedet for `d`), bruk meningsfulle skiller mellom konsepter, bruk søkbare navn (unngå magiske tall og enkelt-bokstav-variabler unntatt i trivielle løkker), og bruk domene-vokabular konsekvent.

• Intention-revealing names: Hva gjør dette – ikke hva det er
• Avoid disinformation: Ikke kall en array "list" hvis det ikke er en list-datastruktur
• Make meaningful distinctions: `a1` og `a2` sier ingenting
• Use pronounceable names: `modymdhms` er uleselig, `modificationTimestamp` er ikke
• Use searchable names: Magiske tall er umulige å søke etter
• Class names: Substantiver og substantivfraser, ikke verb

Funksjoner: Gjør én ting og gjør det godt

Martin argumenterer for at funksjoner skal gjøre én ting, gjøre det godt og gjøre bare det. En funksjon som gjør mer enn én ting er vanskeligere å navngi, teste, lese og gjenbruke. Korthet er ikke et mål i seg selv, men funksjoner bør sjelden være mer enn 20 linjer – og ideelt 5–10.

Antall parametere bør holdes lavt: null er ideelt, én er akseptabel, to er greit, tre krever gode argumenter, og mer enn tre er et designproblem. Switch-setninger, try/catch-blokker og flag-argumenter er tegn på at funksjonen kanskje gjør mer enn én ting.

"Funksjoner bør gjøre én ting. De bør gjøre det godt. De bør gjøre bare det."

Kommentarer: Kompensasjon for dårlig kode?

Martin har et kontroversielt syn på kommentarer: de beste kommentarene er ingen kommentarer, fordi god kode er selvforklarende. Men noen kommentarer er legitime og verdifulle:

SOLID-prinsippene: Grunnlaget for god OO-design

SOLID er et akronym for fem objektorienterte designprinsipper som fremmer vedlikeholdbar og utvidbar kode. Prinsippene ble samlet og navngitt av Robert C. Martin og er i dag grunnleggende kunnskap for alle seriøse softwareutviklere.

Single Responsibility Principle (SRP): En klasse skal ha kun én grunn til å endre seg. Open/Closed Principle (OCP): Klasser skal være åpne for utvidelse, men lukket for modifikasjon. Liskov Substitution Principle (LSP): Subklasser skal kunne erstatte foreldreklassen uten å bryte systemet. Interface Segregation Principle (ISP): Klienter skal ikke tvinges til å avhenge av metoder de ikke bruker. Dependency Inversion Principle (DIP): Høynivåmoduler skal ikke avhenge av lavnivåmoduler – begge skal avhenge av abstraksjoner.

• S – Single Responsibility: Én klasse, én grunn til endring
• O – Open/Closed: Åpen for utvidelse, lukket for modifikasjon
• L – Liskov Substitution: Subklasser erstatter foreldretypen problemfritt
• I – Interface Segregation: Smale grensesnitt over brede
• D – Dependency Inversion: Avheng av abstraksjoner, ikke konkrete implementeringer

Feilhåndtering og unntaksbehandling

Clean code-tilnærmingen til feilhåndtering er å bruke unntak (exceptions) fremfor returkoder, å gi kontekst i feilmeldinger og å definere unntaksklasser basert på behovet til kalleren. Unngå å returnere null – det fører til NullPointerException-orgie. Bruk Optional, Result-typen eller tomme collections i stedet.

Ikke ignorér unntak – en tom catch-blokk er en av de verste tingene man kan gjøre i kode. Håndtér feilen, logger den med kontekst, eller la den propagere oppover til riktig ansvarsnivå. For norske produksjonssystemer er god feilhåndtering og logging essensielt for feilsøking og overvåkning.

Clean code-kultur i norske team

Mange norske teknologiselskaper har innarbeidet clean code-prinsippene i sin utviklingskultur gjennom code reviews, coding standards og kontinuerlig diskusjon. Norsk teknologibransje er generelt høyt utdannet og verdsetter kodekultur, og bøker som Clean Code er vanlige på kontorbibliotekene.

Det er verdt å merke seg at Clean Code har noen kritikere som mener at noen råd (spesielt om korthet) er overdrevet. Det viktigste er å forstå prinsippene og konteksten de gjelder i – ikke å følge dem dogmatisk. Teamets konsensus om hva som er god kode er viktigere enn noen enkeltboks regler.