Clean Code

1. Skriv ren kode som er lesbar og vedlikeholdbar

Den eneste gyldige målingen av kodekvalitet: WTFs/minutt

Lesbarhet er avgjørende. Ren kode bør være lett forståelig for andre utviklere. Den skal være enkel, elegant og fri for rot. Strebe etter å skrive kode som klart uttrykker sin hensikt uten behov for omfattende kommentarer. Bruk meningsfulle variabel- og funksjonsnavn, hold funksjoner små og fokuserte, og organiser koden logisk.

Vedlikeholdbarhet muliggjør utvikling. Kode som er vanskelig å endre, blir en belastning. Design koden din slik at den er fleksibel og modulær, slik at den kan tilpasse seg endrede krav. Følg prinsipper som DRY (Don't Repeat Yourself) og SOLID for å skape løst koblede, høyt sammenhengende systemer. Refaktorer nådeløst for å forbedre kode-strukturen uten å endre oppførselen.

Ren kode lønner seg. Selv om det tar mer tid å skrive ren kode i starten, sparer det betydelig tid og hodebry på lang sikt. Ren kode er lettere å feilsøke, utvide og vedlikeholde. Det gjør det mulig for utviklere å jobbe mer effektivt og reduserer risikoen for å introdusere feil under endringer. Gjør ren kode til en kjernekomponent i utviklingspraksisen din.

2. Følg meningsfulle navnekonvensjoner

Navnet på en variabel, funksjon eller klasse, bør svare på alle de store spørsmålene. Det bør fortelle deg hvorfor det eksisterer, hva det gjør, og hvordan det brukes.

Bruk intensjonsavdekkende navn. Velg navn som klart formidler formålet og oppførselen til variabler, funksjoner og klasser. Unngå enkeltbokstavnavn eller kryptiske forkortelser. Bruk uttalbare navn som kan søkes enkelt. For eksempel:

• Dårlig: d (forløpt tid i dager)
• Bra: forløptTidIDager

Vær konsekvent og presis. Bruk konsekvente navnekonvensjoner gjennom hele kodebasen din. Vær presis for å unngå tvetydighet - for eksempel, bruk meningsfulle distinksjoner som hentAktiveKontoer() og hentAktivKontoInfo(). Unngå koding eller prefikser som tilfører støy uten verdi. Klassenavn bør være substantiv, metodenavn bør være verb.

Navnelengde bør matche omfang. Bruk lengre, mer beskrivende navn for variabler og funksjoner med større omfang. Korte navn er akseptable for små, lokale omfang. Lengden på et navn bør være proporsjonal med bruksomfanget. Optimaliser for lesbarhet og forståelse innen konteksten der navnet brukes.

3. Hold funksjoner små og fokuserte

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

Lite er vakkert. Funksjoner bør være små - typisk 5-10 linjer lange. De bør passe på én skjerm og være umiddelbart forståelige. Ekstraher kode til godt navngitte hjelpefunksjoner i stedet for å skrive lange, komplekse funksjoner. Små funksjoner er lettere å forstå, teste og vedlikeholde.

Gjør én ting godt. Hver funksjon bør ha et enkelt, klart formål. Hvis en funksjon gjør flere ting, ekstraher disse til separate funksjoner. Tegn på at en funksjon gjør for mye inkluderer:

• Flere nivåer av abstraksjon
• Flere seksjoner eller kodeblokker
• Mange parametere

Oppretthold ett nivå av abstraksjon. Utsagnene innen en funksjon bør alle være på samme nivå av abstraksjon. Ikke bland høynivålogikk med lavnivådetaljer. Ekstraher lavnivåoperasjoner til separate funksjoner. Dette forbedrer lesbarheten ved å holde funksjoner fokuserte og konseptuelt enkle.

4. Praktiser riktig formatering og organisering

Kodeformatering handler om kommunikasjon, og kommunikasjon er den profesjonelle utviklerens første prioritet.

Konsistent formatering er viktig. Bruk konsekvent innrykk, linjeskift og mellomrom gjennom koden din. Dette forbedrer lesbarheten og reduserer den kognitive belastningen. Bli enige om formateringsstandarder med teamet ditt og bruk automatiserte verktøy for å håndheve dem. Nøkkelretningslinjer for formatering inkluderer:

• Riktig innrykk
• Konsistent plassering av klammeparenteser
• Logiske linjeskift
• Passende hvitt rom

Organiser koden logisk. Grupper relaterte koder sammen og separer urelaterte koder. Bruk blanke linjer for å lage "avsnitt" mellom logiske seksjoner. Plasser relaterte funksjoner nær hverandre. Hold filer fokusert på et enkelt konsept eller komponent. Del store filer opp i mindre, mer fokuserte når det er hensiktsmessig.

Følg standard konvensjoner. Hold deg til standard konvensjoner for språket og fellesskapet ditt. Dette gjør koden din mer kjent og tilgjengelig for andre utviklere. For eksempel, i Java:

• Klassenavn bruker PascalCase
• Metodenavn bruker camelCase
• Konstanter bruker ALL_CAPS

5. Håndter avhengigheter og unngå duplisering

Duplisering kan være roten til alt ondt i programvare.

Eliminer duplisering. Duplisert kode er en tapt mulighet for abstraksjon. Når du ser duplisering, ekstraher den felles koden til en gjenbrukbar funksjon eller klasse. Dette forbedrer vedlikeholdbarheten ved å sentralisere logikk og redusere risikoen for inkonsekvente endringer. Typer duplisering å se etter:

• Identiske kodeblokker
• Lignende algoritmer med små variasjoner
• Gjentatte switch/case eller if/else-kjeder

Håndter avhengigheter nøye. Minimer avhengigheter mellom moduler for å redusere kobling. Bruk avhengighetsinjeksjon og kontrollinversjon for å gjøre koden mer modulær og testbar. Følg prinsippet om avhengighetsinversjon - avheng av abstraksjoner, ikke konkretiseringer. Dette gjør koden din mer fleksibel og lettere å endre.

Bruk prinsippet om minst kunnskap. En modul bør ikke vite om innholdet i objektene den manipulerer. Dette reduserer koblingen mellom moduler. For eksempel, bruk Demeter-loven - en metode bør bare kalle metoder på:

• Dens eget objekt
• Objekter som sendes som parametere
• Objekter den oppretter
• Dens direkte komponentobjekter

6. Håndter feil på en elegant måte

Feilhåndtering er viktig, men hvis det skjuler logikk, er det galt.

Bruk unntak i stedet for feilkoder. Unntak er renere og rotete ikke hovedlogikken i koden din. De lar feilhåndtering være adskilt fra den lykkelige stien. Når du bruker unntak:

• Lag informative feilmeldinger
• Gi kontekst med unntak
• Definer unntaksklasser basert på behovene til den som kaller

Ikke returner null. Å returnere null fører til nullpekerfeil og rotete kode med nullsjekker. I stedet:

• Returner tomme samlinger i stedet for null for lister
• Bruk Null Object-mønsteret
• Bruk Optional i Java eller Maybe i funksjonelle språk

Skriv try-catch-finally-setninger først. Start med try-catch-finally når du skriver kode som kan kaste unntak. Dette hjelper med å definere omfanget og forventningene for den kallende koden. Det sikrer at ressurser blir riktig håndtert og frigjort, selv i feilsituasjoner.

7. Skriv grundige enhetstester

Testkode er like viktig som produksjonskode.

Følg de tre lovene i TDD. Testdrevet utvikling (TDD) forbedrer kodekvalitet og design:

1. Skriv en test som feiler før du skriver noen produksjonskode
2. Skriv bare nok av en test for å demonstrere en feil
3. Skriv bare nok produksjonskode for å bestå testen

Hold tester rene og vedlikeholdbare. Bruk de samme standardene for kodekvalitet på testene dine som på produksjonskoden din. Refaktorer og forbedre testkoden regelmessig. Godt strukturerte tester fungerer som dokumentasjon og muliggjør fryktløs refaktorisering av produksjonskode.

Sikt mot omfattende testdekning. Skriv tester som dekker kanttilfeller, grensebetingelser og feilsituasjoner - ikke bare den lykkelige stien. Bruk kode-dekningsverktøy for å identifisere hull i testdekningen. Husk at 100 % dekning ikke garanterer feilfri kode, men det gir trygghet ved refaktorisering og endringer.

8. Refaktorer kode kontinuerlig

La leiren være renere enn du fant den.

Refaktorer opportunistisk. Forbedre kode-strukturen når som helst du jobber med en del av koden. Følg Boy Scout-regelen: la koden være bedre enn du fant den. Små, inkrementelle forbedringer legger seg opp over tid og forhindrer kodeforfall. Vanlige refaktoreringsmetoder inkluderer:

• Ekstrahere metoder eller klasser
• Omdøpe for klarhet
• Forenkle komplekse betingelser
• Fjerne duplisering

Refaktorer trygt med tester. Ha alltid et solid testsett før du refaktorerer. Gjør små, inkrementelle endringer og kjør tester ofte. Dette gir deg trygghet for at endringene dine ikke bryter eksisterende funksjonalitet. Bruk automatiserte refaktoreringsverktøy når tilgjengelig for å redusere risikoen for å introdusere feil.

Balansere refaktorisering med å levere verdi. Selv om kontinuerlig refaktorisering er viktig, ikke la det lamme fremdriften. Sikt mot "godt nok" i stedet for perfeksjon. Fokuser refaktoreringsinnsatsen på de mest problematiske eller ofte endrede områdene av koden. Kommuniser verdien av refaktorisering til interessenter for å sikre støtte for kontinuerlig kodeforbedring.

9. Anvend objektorienterte og funksjonelle programmeringsprinsipper

Objekter skjuler dataene sine bak abstraksjoner og eksponerer funksjoner som opererer på disse dataene. Datastrukturer eksponerer dataene sine og har ingen meningsfulle funksjoner.

Bruk objektorienterte prinsipper med omhu. Anvend prinsipper som innkapsling, arv og polymorfisme for å skape fleksible, modulære design. Følg SOLID-prinsippene:

• Enkeltansvarsprinsippet
• Åpen-lukket prinsipp
• Liskov substitusjonsprinsipp
• Grensesnitt-segregeringsprinsipp
• Avhengighetsinversjonsprinsipp

Utnytt funksjonelle programmeringskonsepter. Selv i objektorienterte språk kan funksjonelle programmeringsteknikker føre til renere kode:

• Rene funksjoner uten bivirkninger
• Immutable data
• Høyere ordens funksjoner
• Funksjonskomposisjon

Velg riktig tilnærming for problemet. Objektorienterte og funksjonelle paradigmer har hver sine styrker og svakheter. Bruk objektorientert design når du trenger å modellere komplekse domener med atferd. Bruk funksjonelle tilnærminger for datatransformasjon og behandlingspipelines. Mange moderne språk støtter en hybrid tilnærming, som lar deg bruke det beste verktøyet for hver del av systemet ditt.

10. Vurder samtidighet nøye

Samtidighet er en avkoblingsstrategi. Den hjelper oss å skille hva som blir gjort fra når det blir gjort.

Forstå samtidighetsutfordringer. Samtidig programmering introduserer kompleksitet og potensial for subtile feil. Vanlige problemer inkluderer:

• Kappløpsforhold
• Dødlåser
• Glemte signaler
• Problemer med minnesynlighet

Skille samtidighetsbekymringer. Hold koden relatert til samtidighet adskilt fra annen kode. Dette gjør det lettere å resonnere om og teste. Bruk abstraksjoner som Executors, Futures og Actors for å håndtere samtidighet i stedet for å jobbe med rå tråder.

Foretrekke immutabilitet og rene funksjoner. Immutable objekter og rene funksjoner er iboende trådsikre. De eliminerer mange samtidighetsproblemer ved å unngå delt, muterbar tilstand. Når muterbar tilstand er nødvendig, bruk riktige synkroniseringsteknikker og vurder å bruke atomiske variabler eller samtidige samlinger.

Last updated: January 22, 2025