Één van de features van je app is, zelfs als de gebruikers dit niet zien, de leesbaarheid van je code.
Ik houd me altijd aan vijf regels om de leesbaarheid van mijn code zo goed mogelijk te houden. Ik heb deze regels geleerd in allerlei projecten, teams en organisaties. En ik deel ze graag met iedereen die de leesbaarheid van zijn of haar code wil verbeteren! Ik hoop dat je uit deze blog minstens één nieuwe regel leert en meeneemt in jouw eigen code.
Voor iedereen die op zoek is naar snelle tips zonder alles te lezen, lees de TL; DR-versie hieronder:
- Hergebruik onderdelen die je vaker gebruikt.
- Leesbaarheid en ‘onderhoudbaarheid’ zijn belangrijker dan het gebruiken van een generieke oplossing.
- Maak modules, classes en componenten zo klein mogelijk.
- Automatiseer regels en richtlijnen voor je code.
- Codeer alsof je in een team zit, zelfs al bestaat je team uit één persoon.
1. Hergebruik onderdelen die je vaker gebruikt.
De meeste ontwikkelaars weten wat D.R.Y. betekent: Don’t Repeat Yourself. Herhaal jezelf niet. D.R.Y. kan je helpen om codeduplicatie te voorkomen.
Waarom zou je een functie steeds opnieuw schrijven? Één keer schrijven en het op meerdere plaatsen opnieuw gebruiken is veel logischer. Wanneer je de code moet aanpassen, hoef je dan slechts op één plek te kijken in plaats van het doorvoeren van een bugfix op meerdere plekken.
Houd er echter rekening mee dat D.R.Y. ook complexiteit met zich meebrengt, omdat dingen uiteindelijk steeds vaker zullen worden hergebruikt. Wanneer je je code wijzigt, zal het heel duidelijk worden waarom het schrijven van tests zeer belangrijk is bij het hergebruiken van delen van je code.
2. Leesbaarheid en ‘onderhoudbaarheid’ zijn belangrijker dan het gebruiken van een generieke oplossing.
Herbruikbaarheid, leesbaarheid en onderhoudbaarheid zijn zowel elkaars vrienden als elkaars vijanden. Wanneer je D.R.Y. gaat gebruiken in je code, introduceer je complexiteit. Wanneer je complexiteit introduceert, kan de leesbaarheid omlaag gaan.
Begin bij het bouwen van functies dus niet meteen met een algemene oplossing. Begin eenvoudig. De eerste code zal nooit perfect zijn. Met iteraties kan je delen van de applicatie hergebruiken, zonder de leesbaarheid en onderhoudbaarheid te verliezen.
Wanneer je werkt in een organisatie met veel ontwikkelteams, zal je team bestaan uit in- en externe medewerkers. Denk hierbij aan freelancers en consultants. In dit geval zullen mensen dus vaker wisselen tussen verschillende organisaties.
In die gevallen zijn leesbaarheid en onderhoudbaarheid de sleutels tot succes. Generieke oplossingen geïmplementeerd door één persoon die gemakkelijk het team zou kunnen verlaten, zijn geen slimme keuze. Wanneer een volgende ontwikkelaar een andere werkwijze heeft, gaan deze werkwijzen door elkaar lopen. Dit heeft een negatief effect op de onderhoudbaarheid van de code.
In sommige gevallen zijn generieke oplossingen nodig, maar die oplossingen moeten uiteraard nog wel leesbaar en onderhoudbaar zijn.
3. Maak modules, classes of componenten zo klein mogelijk.
Wanneer je nieuwe features voor een applicatie bouwt, plan je deze waarschijnlijk zorgvuldig.
De beste oplossingen zijn oplossingen die kunnen worden onderverdeeld in kleine modules, classes of componenten. Vraag je je af waarom?
Kleine stukjes code zijn eenvoudiger te testen en te onderhouden.
Stel je voor dat een hoog gebouw ook wordt gebouwd met behulp van kleinere componenten die worden verplaatst, in plaats van dat het gebouw in één keer wordt gebouwd en vervolgens naar de locatie wordt verplaatst… oké, er zijn uitzonderingen.
De meeste moderne libraries en frameworks zijn onderverdeeld in kleinere bouwstenen in plaats van één bestand. Bijvoorbeeld JavaScript-libraries en frameworks zoals Angular, React en Vue.JS passen dit concept van componenten toe. Dit doen ze echt niet per ongeluk.
4. Automatiseer regels en richtlijnen voor je code.
Het schrijven van leesbare en onderhoudbare code bestaat voor een groot deel uit de architectuur. Een ander deel is de stijl van de code.
Velen van jullie zijn waarschijnlijk bekend met de discussie over het gebruik van tabs of spaties voor inspringen. Nee, ik ga niet verder met die discussie. Het kan allebei. Wat je ook gebruikt in jouw team, zorg ervoor dat het voor iedereen duidelijk is en iedereen zich hier aan houdt.
De beste oplossing is om deze stijlregels en -richtlijnen (voor een deel) te automatiseren. Bij veel IDE’s is dit geïntegreerd of zijn er plug-ins voor beschikbaar.
De gemakkelijkste, die werkt met meerdere talen én code editors, is editorconfig. Door een .editorconfig toe te voegen, worden deze regels automatisch toegepast. In die bestanden kan je instellingen voor de stijl van je code doorvoeren. Je kunt ze globaal en voor specifieke talen instellen. Bijvoorbeeld:
- Inspringstijl: tabs of spaties
- Quote type: enkel of dubbel
- Maximale lengte
- Karakterset
Dit is een configuratie in een van mijn projecten:
# Editor configuration, see https://editorconfig.org
root = true[*]
charset = utf-8
indent_style = space
indent_size = 2
insert_final_newline = true
trim_trailing_whitespace = true[*.ts]
quote_type = single[*.md]
max_line_length = off
trim_trailing_whitespace = false
Er zijn veel meer tools die specifiek zijn voor bepaalde talen. Ik gebruik Prettier graag voor JavaScript, maar misschien wil jij wel iets anders gebruiken. Welke tool je gebruikt is niet belangrijk, zolang iedereen die aan het project werkt maar dezelfde regels en richtlijnen aanhoudt.
5. Codeer alsof je in een team zit, zelfs al bestaat je team uit één persoon.
En last but not least: schrijf alsof je in een team zit!
Ik kan me voorstellen dat het erg moeilijk is om te begrijpen wat ik daarmee bedoel, als je nog nooit code in een team hebt geschreven.
Maar als je zelf een project programmeert, is het erg verleidelijk om code te schrijven die alleen jij begrijpt (denk aan het schrijven van onduidelijke variabele-namen en variabelenamen van 2 tot 3 tekens).
Probeer je code te schrijven alsof je in een team zit. Stel je voor dat je code zo duidelijk is dat iemand anders je code gemakkelijk kan begrijpen. Op deze manier blijft het voor jou zelf ook duidelijk, ook als je een langere tijd niet naar je code kijkt.
Je kunt dit eenvoudig testen door een vriend of iemand via Twitter in de ontwikkelaarscommunity te vragen om de leesbaarheid van je code te controleren. Ik kan je beloven dat je feedback krijgt waar je zelf nooit aan hebt gedacht.
Het kan natuurlijk ook zijn dat je dan negatieve feedback krijgt. Raak hier niet van in paniek! Focus je op de feedback die antwoord geeft op jouw vraag: hoe kan ik mijn code leesbaarder maken voor iemand anders?
Het is belangrijk om te weten dat er slechts een dunne lijn zit tussen leesbare code en niet-zo-leesbare code. Dit is allemaal gebaseerd op de mening van één persoon. Voel je er niet rot over als iemand je vertelt dat jouw code niet goed leesbaar is. Wees dankbaar voor de feedback en verbeter je code.
Conclusie
Bedankt voor het lezen van deze blog! Ik hoop dat je ten minste één ding uit dit artikel hebt geleerd en in de toekomst meer aandacht hebt voor de leesbaarheid van je code. Zo zorgen we met ze allen voor een wereld met overzichtelijke code!
Heb je zelf een tip voor meer leesbare code, dan horen we het graag! Ook als één van onze ontwikkelaars kan helpen met het leesbaar en onderhoudbaar maken van jouw code, horen we het graag. We worden maar wat graag betrokken bij projecten die we met onze kennis en inzichten kunnen verbeteren.
De originele, Engelstalige versie van deze blog vind je hier: 5 rules to improve code readability. Deze is ook geschreven door onze collega en vertaald voor onze eigen website.
Heb je vragen over dit onderwerp of zou je Raymon willen inhuren voor een vergelijkbare opdracht?
Lees ook onze andere berichten
Heb je een Front-End Developer nodig?