Clean Code

1. Schrijf schone code die leesbaar en onderhoudbaar is

De enige geldige maatstaf voor codekwaliteit: WTFs/minuut

Leesbaarheid is van het grootste belang. Schone code moet gemakkelijk te begrijpen zijn voor andere ontwikkelaars. Het moet eenvoudig, elegant en vrij van rommel zijn. Streef ernaar om code te schrijven die zijn intentie duidelijk uitdrukt zonder uitgebreide opmerkingen. Gebruik betekenisvolle variabelen en functienamen, houd functies klein en gefocust, en organiseer de code logisch.

Onderhoudbaarheid maakt evolutie mogelijk. Code die moeilijk te veranderen is, wordt een last. Ontwerp je code zo dat deze flexibel en modulair is, zodat deze kan inspelen op veranderende vereisten. Volg principes zoals DRY (Don't Repeat Yourself) en SOLID om losjes gekoppelde, hoog cohesieve systemen te creëren. Refactor zonder genade om de code-structuur te verbeteren zonder het gedrag te veranderen.

Schone code loont. Hoewel het schrijven van schone code meer inspanning vooraf vergt, bespaart het op de lange termijn aanzienlijke tijd en hoofdpijn. Schone code is gemakkelijker te debuggen, uit te breiden en te onderhouden. Het stelt ontwikkelaars in staat om efficiënter te werken en vermindert het risico op het introduceren van bugs tijdens wijzigingen. Maak schone code een kernonderdeel van je ontwikkelingspraktijk.

2. Volg betekenisvolle naamgevingsconventies

De naam van een variabele, functie of klasse moet alle grote vragen beantwoorden. Het moet je vertellen waarom het bestaat, wat het doet en hoe het wordt gebruikt.

Gebruik intentioneel onthullende namen. Kies namen die duidelijk het doel en gedrag van variabelen, functies en klassen overbrengen. Vermijd eenletterige namen of cryptische afkortingen. Gebruik uitspreekbare namen die gemakkelijk te doorzoeken zijn. Bijvoorbeeld:

• Slecht: d (verstreken tijd in dagen)
• Goed: verstrekenTijdInDagen

Wees consistent en precies. Gebruik consistente naamgevingsconventies door je codebase heen. Wees precies om ambiguïteit te vermijden - gebruik bijvoorbeeld betekenisvolle onderscheidingen zoals getActiveAccounts() en getActiveAccountInfo(). Vermijd coderingen of voorvoegsels die ruis toevoegen zonder waarde. Klassenamen moeten zelfstandige naamwoorden zijn, methodenamen moeten werkwoorden zijn.

De naam lengte moet overeenkomen met de scope. Gebruik langere, beschrijvende namen voor variabelen en functies met grotere scopes. Korte namen zijn acceptabel voor kleine, lokale scopes. De lengte van een naam moet proportioneel zijn aan de gebruiksscope. Optimaliseer voor leesbaarheid en begrip binnen de context waarin de naam wordt gebruikt.

3. Houd functies klein en gefocust

Functies moeten één ding doen. Ze moeten het goed doen. Ze moeten het alleen doen.

Klein is mooi. Functies moeten klein zijn - typisch 5-10 regels lang. Ze moeten op één scherm passen en onmiddellijk begrijpelijk zijn. Extraheer code in goed benoemde hulpfuncties in plaats van lange, complexe functies te schrijven. Kleine functies zijn gemakkelijker te begrijpen, testen en onderhouden.

Doe één ding goed. Elke functie moet een enkel, duidelijk doel hebben. Als een functie meerdere dingen doet, extraheer die dan in aparte functies. Tekenen dat een functie te veel doet zijn onder andere:

• Meerdere niveaus van abstractie
• Meerdere secties of codeblokken
• Talrijke parameters

Behoud één niveau van abstractie. De uitspraken binnen een functie moeten allemaal op hetzelfde abstractieniveau zijn. Meng geen hoge logica met lage details. Extraheer lagere operaties in aparte functies. Dit verbetert de leesbaarheid door functies gefocust en conceptueel eenvoudig te houden.

4. Oefen juiste opmaak en organisatie

Code-opmaak gaat over communicatie, en communicatie is de eerste prioriteit van de professionele ontwikkelaar.

Consistente opmaak is belangrijk. Gebruik consistente inspringing, regelafbrekingen en spatiëring door je code. Dit verbetert de leesbaarheid en vermindert de cognitieve belasting. Stem opmaakstandaarden af met je team en gebruik geautomatiseerde tools om deze af te dwingen. Belangrijke opmaakrichtlijnen zijn onder andere:

• Juiste inspringing
• Consistente plaatsing van accolades
• Logische regelafbrekingen
• Geschikte witruimtes

Organiseer code logisch. Groepeer gerelateerde code en scheid niet-gerelateerde code. Gebruik lege regels om "paragraaf" onderbrekingen tussen logische secties te creëren. Plaats gerelateerde functies dicht bij elkaar. Houd bestanden gefocust op een enkel concept of component. Breek grote bestanden op in kleinere, meer gefocuste bestanden wanneer dat nodig is.

Volg standaardconventies. Houd je aan standaardconventies voor je taal en gemeenschap. Dit maakt je code bekender en toegankelijker voor andere ontwikkelaars. Bijvoorbeeld, in Java:

• Klassenamen gebruiken PascalCase
• Methodennamen gebruiken camelCase
• Constanten gebruiken ALL_CAPS

5. Beheer afhankelijkheden en vermijd duplicatie

Duplicatie kan de wortel van alle kwaad in software zijn.

Elimineer duplicatie. Gedupliceerde code is een gemiste kans voor abstractie. Wanneer je duplicatie ziet, extraheer de gemeenschappelijke code in een herbruikbare functie of klasse. Dit verbetert de onderhoudbaarheid door logica te centraliseren en het risico op inconsistente wijzigingen te verminderen. Soorten duplicatie om op te letten zijn onder andere:

• Identieke codeblokken
• Vergelijkbare algoritmen met kleine variaties
• Herhaalde switch/case of if/else-ketens

Beheer afhankelijkheden zorgvuldig. Minimaliseer afhankelijkheden tussen modules om de koppeling te verminderen. Gebruik afhankelijkheidsinjectie en inversie van controle om code modulairder en testbaarder te maken. Volg het Dependency Inversion Principle - afhankelijk zijn van abstracties, niet van concreties. Dit maakt je code flexibeler en gemakkelijker te veranderen.

Gebruik het principe van de minste kennis. Een module mag niet weten over de interne werking van de objecten die het manipuleert. Dit vermindert de koppeling tussen modules. Gebruik bijvoorbeeld de Wet van Demeter - een methode mag alleen methoden aanroepen op:

• Zijn eigen object
• Objecten die als parameters zijn doorgegeven
• Objecten die het creëert
• Zijn directe componentobjecten

6. Behandel fouten op een elegante manier

Foutafhandeling is belangrijk, maar als het de logica vertroebelt, is het verkeerd.

Gebruik uitzonderingen in plaats van foutcodes. Uitzonderingen zijn schoner en rommelen de hoofdlogica van je code niet op. Ze stellen foutafhandeling in staat om gescheiden te zijn van het gelukkige pad. Bij het gebruik van uitzonderingen:

• Maak informatieve foutmeldingen
• Bied context met uitzonderingen
• Definieer uitzonderingsklassen op basis van de behoeften van de aanroeper

Geef geen null terug. Het retourneren van null leidt tot null pointer-excepties en rommelt de code op met null-controles. In plaats daarvan:

• Geef lege collecties terug in plaats van null voor lijsten
• Gebruik het Null Object-patroon
• Gebruik Optional in Java of Maybe in functionele talen

Schrijf try-catch-finally-statements eerst. Begin met de try-catch-finally bij het schrijven van code die uitzonderingen kan genereren. Dit helpt de scope en verwachtingen voor de aanroepende code te definiëren. Het zorgt ervoor dat middelen goed worden beheerd en vrijgegeven, zelfs in foutscenario's.

7. Schrijf grondige eenheidstests

Testcode is net zo belangrijk als productcode.

Volg de drie wetten van TDD. Test-Driven Development (TDD) verbetert de codekwaliteit en het ontwerp:

1. Schrijf een falende test voordat je enige productcode schrijft
2. Schrijf alleen genoeg van een test om een falen aan te tonen
3. Schrijf alleen genoeg productcode om de test te laten slagen

Houd tests schoon en onderhoudbaar. Pas dezelfde normen voor codekwaliteit toe op je tests als op je productcode. Refactor en verbeter testcode regelmatig. Goed gestructureerde tests dienen als documentatie en stellen je in staat om zonder angst productcode te refactoren.

Streef naar uitgebreide testdekking. Schrijf tests die randgevallen, grensvoorwaarden en foutscenario's dekken - niet alleen het gelukkige pad. Gebruik code-dekkingstools om hiaten in testdekking te identificeren. Onthoud dat 100% dekking geen garantie biedt voor bugvrije code, maar het biedt vertrouwen in refactoring en wijzigingen.

8. Refactor code continu

Laat de camping schoner achter dan je hem vond.

Refactor opportunistisch. Verbeter de code-structuur telkens wanneer je aan een stuk code werkt. Volg de Boy Scout Rule: laat de code beter achter dan je hem vond. Kleine, incrementele verbeteringen tellen op in de loop van de tijd en voorkomen code-rot. Veelvoorkomende refactoringstechnieken zijn onder andere:

• Methoden of klassen extraheren
• Hernoemen voor duidelijkheid
• Complexe conditionals vereenvoudigen
• Duplicatie verwijderen

Refactor veilig met tests. Zorg altijd voor een solide suite van tests voordat je refactort. Maak kleine, incrementele wijzigingen en voer tests regelmatig uit. Dit geeft je vertrouwen dat je wijzigingen de bestaande functionaliteit niet breken. Gebruik geautomatiseerde refactoringtools wanneer beschikbaar om het risico op het introduceren van fouten te verminderen.

Balans refactoren met waarde leveren. Hoewel continue refactoring belangrijk is, laat het je niet verlammen in de voortgang. Streef naar "goed genoeg" in plaats van perfectie. Focus refactoring-inspanningen op de meest problematische of vaak veranderde gebieden van de code. Communiceer de waarde van refactoring naar belanghebbenden om ervoor te zorgen dat er steun is voor voortdurende codeverbetering.

9. Pas objectgeoriënteerde en functionele programmeerprincipes toe

Objecten verbergen hun gegevens achter abstracties en stellen functies bloot die op die gegevens werken. Gegevensstructuren stellen hun gegevens bloot en hebben geen betekenisvolle functies.

Gebruik objectgeoriënteerde principes verstandig. Pas principes zoals encapsulatie, overerving en polymorfisme toe om flexibele, modulaire ontwerpen te creëren. Volg de SOLID-principes:

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Benut functionele programmeerconcepten. Zelfs in objectgeoriënteerde talen kunnen functionele programmeertechnieken leiden tot schonere code:

• Pure functies zonder bijwerkingen
• Onveranderlijke gegevens
• Hogere-orde functies
• Functiesamenstelling

Kies de juiste aanpak voor het probleem. Objectgeoriënteerde en functionele paradigma's hebben elk hun sterke en zwakke punten. Gebruik objectgeoriënteerd ontwerp wanneer je complexe domeinen met gedrag moet modelleren. Gebruik functionele benaderingen voor gegevensverwerking en transformatie. Veel moderne talen ondersteunen een hybride aanpak, waardoor je het beste gereedschap voor elk deel van je systeem kunt gebruiken.

10. Overweeg gelijktijdigheid zorgvuldig

Gelijktijdigheid is een ontkoppelingsstrategie. Het helpt ons te ontkoppelen wat er gedaan wordt van wanneer het gedaan wordt.

Begrijp de uitdagingen van gelijktijdigheid. Gelijktijdig programmeren introduceert complexiteit en de mogelijkheid van subtiele bugs. Veelvoorkomende problemen zijn onder andere:

• Racecondities
• Deadlocks
• Gemiste signalen
• Problemen met geheugenzichtbaarheid

Scheiding van gelijktijdigheidszorgen. Houd je gelijktijdigheidsgerelateerde code gescheiden van andere code. Dit maakt het gemakkelijker om erover na te denken en te testen. Gebruik abstracties zoals Executors, Futures en Actors om gelijktijdigheid te beheren in plaats van met ruwe threads te werken.

Geef de voorkeur aan onveranderlijkheid en pure functies. Onveranderlijke objecten en pure functies zijn van nature thread-safe. Ze elimineren veel gelijktijdigheidsproblemen door gedeelde veranderlijke toestand te vermijden. Wanneer veranderlijke toestand noodzakelijk is, gebruik dan de juiste synchronisatietechnieken en overweeg het gebruik van atomische variabelen of gelijktijdige collecties.

Laatst bijgewerkt: January 22, 2025