Inhoudsopgave
Code wordt vaker gelezen dan geschreven. Jij schrijft een functie één keer, maar jezelf of een collega leest hem tientallen keren — bij een bugfix, een refactor of een code review. Toch behandelen veel developers leesbaarheid als een bijzaak, iets wat je doet als er tijd over is. Dat is een kostbare misvatting. Onleesbare code vertraagt elk team, verhoogt de kans op bugs en maakt onboarding van nieuwe developers onnodig zwaar. Investeren in leesbaarheid is investeren in de toekomst van je project.
Naamgeving als documentatie
De naam van een variabele, functie of klasse is de eerste uitleg die een lezer krijgt. data, temp of x vertellen niets — userInvoices, calculateShippingCost of isEmailVerified vertellen alles. Goede naamgeving elimineert de behoefte aan comments omdat de code zichzelf uitlegt. Een handige vuistregel: als je een comment nodig hebt om uit te leggen wat een variabele doet, is de naam waarschijnlijk niet goed genoeg. Neem de tijd om namen te kiezen die de intentie beschrijven, niet de implementatie.
Kleine functies, één verantwoordelijkheid
Een functie die twintig dingen doet is niet krachtig, hij is onbeheersbaar. Het Single Responsibility Principle stelt dat elke functie precies één ding moet doen en dat goed. Kleine, gefocuste functies zijn makkelijker te lezen, te testen en te hergebruiken. Als je een functie niet in één zin kunt beschrijven zonder “en” te gebruiken, is het waarschijnlijk tijd om hem op te splitsen. Dit geldt ook voor klassen en modules — hoe scherper de afbakening, hoe begrijpelijker het geheel.
Comments die waarde toevoegen
Comments zijn geen vervanging voor slechte code, maar ze hebben wel degelijk een plek. Het verschil zit in wat je documenteert. Leg niet uit wát de code doet — dat moet de code zelf doen. Leg uit waaróm iets op een bepaalde manier is geïmplementeerd, zeker als het een niet-voor-de-hand-liggende keuze is. Een comment als // tijdelijk uitgeschakeld vanwege bug in externe API, zie ticket #342 is waardevol. Een comment als // verhoog i met 1 boven i++ is ruis die je beter kunt weglaten.
Consistentie boven persoonlijke voorkeur
In een codebase met meerdere developers ontstaat snel een lappendeken van stijlen als er geen afspraken zijn. De ene developer gebruikt camelCase, de andere snake_case. De ene zet accolades op dezelfde regel, de andere op de volgende. Die inconsistentie maakt code moeilijker te lezen omdat je brein steeds moet schakelen. Een linter en formatter zoals ESLint met Prettier, of Black voor Python, dwingen consistentie af zonder discussie. Maak die keuzes eenmalig, leg ze vast en automatiseer de handhaving.
Refactoren als gewoonte
Leesbare code ontstaat zelden in één keer. De eerste versie is vaak functioneel maar ruw — en dat is prima. De fout is om die ruwe versie nooit meer aan te raken. Behandel refactoren als een normaal onderdeel van je workflow, niet als een apart project dat je “ooit” oppakt. De boyscout-regel is hier van toepassing: laat code altijd iets schoner achter dan je hem aantrof. Kleine verbeteringen die je consistent doorvoert stapelen zich op tot een codebase waar iedereen prettig in werkt.