Best coding practices: 6 trin til ren kode

Som udvikler kender du sikkert frustrationen over at arbejde med en andens kode: den kan være rodet, indforstået, inkonsekvent - måske er der endda en, der bruger tabs i stedet for spaces!

Uanset hvilke(t) sprog, du skriver på, gør du livet nemmere både for dig selv og andre, der senere måtte arbejde videre med din kode, hvis du følger disse enkle guidelines:

1. Skriv korte enheder:

Korte enheder er nemmere at forstå, teste, analysere og genbruge. Derfor er det en fordel at holde dine enheder korte - eller splitte dem op.

Teoretisk set kan der være en performance penalty for at have flere enheder, fordi flere enheder betyder flere metodekald - i praksis vil det dog sjældent være et spørgsmål om andet end mikrosekunder, og fordelene ved korte enheder vil derfor for langt de fleste klart opveje ulempen.

2. Undgå komplekse enheder

Jo enklere dine enheder er, jo nemmere er de at tilpasse og teste.

Det er selvfølgelig altid et definitionsspørgsmål, hvornår en kode er kompleks; men når en kode bliver tilstrækkelig kompleks, begynder det at blive risikabelt og meget tidskrævende at lave ændringer - for ikke at tale om at teste ændringerne bagefter.

3. Undgå at kopiere kode

Kopier aldrig din kode, selvom det kan være fristende. Har der sneget sig en fejl ind, er den også duplikeret og skal rettes mange steder - som du først skal finde, fx med et clone detection tool. Skriv i stedet en metode, du kan genanvende, og kald den fra forskellige sammenhænge, så der kun skal rettes det ene sted, hvis der viser sig at være fejl i metoden.

Undgå også at kopiere kode fra en anden kodebase. Hvis den originale kodebase stadig bliver vedligeholdt, er det smartere at importere den ønskede funktionalitet ved at tilføje den anden kodebase til din classpath. Og bliver den ikke længere vedligeholdt, bør du slet ikke kopiere den - så risikerer du at dine kode er forældet med det samme.

4. Hold enhedsgrænsefladerne små

Undgå lange parameterlister eller enhedsgrænseflader ved at begrænse antallet af parametre. Store grænseflader gør dine metoder mindre gennemskuelige - og kan ofte indikere flere ansvarligheder. Til gengæld gør korte grænseflader enhederne nemmere at forstå og genbruge.

5. Undgå komplekse, tæt koblede moduler

Som Charles Perrow påpegede i sin bog Natural Accidents i 1999, er ulykker praktisk talt uundgåelige i et system, der både er komplekst og tæt koblet. I et løst koblet system derimod vil en hændelse typisk kun vil påvirke en lille del af systemet, og vil brede sig langsomt, så du har tid til at gribe ind og stoppe skaden.

Det kan virke svært grænsende til det umulige at holde dine systemer løst koblede i praksis. Når du fx bygger videre på et eksisterende system, kommer der som regel nye forbindelser på kryds og tværs, som gør det sværere for både designere og operatører at forudse konsekvenserne af en ændring.

Lav derfor bevidst opdelinger, som begrænser kompleksiteten og dermed konsekvenserne af et uheld. Det gør det også nemmere at arbejde på isolerede dele af din kodebase.

6. Undgå tæt koblede arkitekturkomponenter

Minimer den relative mængde kode inden for moduler, der er eksponeret for (dvs. kan modtage opkald fra) moduler i andre komponenter, så du opnår en løs kobling mellem dine topniveaukomponenter. Det betyder, at du kan opretholde uafhængige komponenter isoleret, hvilket gør dem nemmere at vedligeholde.