Linting is het automatisch scannen van broncode op fouten, verdachte patronen en stijlovertredingen, zonder het programma echt te draaien. Een tool die linter heet, leest de code, vergelijkt hem met een set regels en meldt alles wat fout of inconsistent lijkt. ESLint voor JavaScript en Ruff voor Python zijn twee bekende voorbeelden.
Zie het als een spellingcontrole in een tekstverwerker. Terwijl je typt, streept hij stilletjes het verkeerd gespelde woord en de komma op de verkeerde plek aan, zodat die fout nooit in het eindstuk belandt. Een linter doet hetzelfde met code: hij wijst de vergeten haak of de variabele die niemand gebruikt aan voordat die code bij jouw klanten komt. Zo blijft de codebase clean en consistent, en dat telt vooral als meerdere developers in dezelfde bestanden werken.
De regels liggen niet in beton gegoten. Een team kiest een gedeelde config, zet de checks uit waar het het niet mee eens is, en voegt eigen regels toe. Een linter kan waarschuwen dat een variabele wel wordt aangemaakt maar nooit gelezen, of een gelijkheidscheck markeren die de verkeerde types vergelijkt, het soort bug dat aan een snelle blik ontsnapt maar tijdens het draaien stukgaat.
Linters draaien meestal op drie plekken: in de editor van de developer terwijl die typt, als check tijdens de code review, en automatisch in de buildpijplijn zodat er niets doorglipt. Omdat de regels één keer worden afgesproken en door een machine worden toegepast, verspilt de review geen tijd meer aan opmaak en gaat de aandacht naar de logica.
Bij TopDevs zetten we linting op dag één van elk project op, zodat de code consistent blijft hoeveel mensen er ook aan werken en kleine bugs allang weg zijn voordat een gebruiker ze ziet.
