steeds meer teams hebben linters en andere statische tools gebruikt in hun ontwikkelingsproces. Sommigen integreerden ze in de IDE van hun voorkeur, anderen geautomatiseerd door ze uit te voeren als een extra stap in hun CI. Sommige lopen ook beide kanten op.
Wat is dan een linter?
volgens Wikipedia is linter
een tool die broncode analyseert om programmeerfouten, bugs, stilistische fouten en verdachte constructies te markeren.,
de eerste linter werd geschreven door Stephen C. Johnson in 1978 tijdens het werken in het UNIX-besturingssysteem bij Bell Labs. Daarna zijn er veel andere linters verschenen voor verschillende doeleinden en talen, niet alleen C.
de eerste linters die werden gebruikt om de broncode te controleren en potentiële optimalisaties voor compilers te vinden. Maar in de loop van de jaren zouden vele andere controles en analyses worden opgenomen in het proces van linting.
het gebruik van linters heeft ook veel ontwikkelaars geholpen om betere code te schrijven voor niet gecompileerde programmeertalen., Omdat er geen tijdfouten worden gecompileerd, typefouten, syntaxisfouten worden gevonden, gebruik wordt gemaakt van niet-aangegeven variabelen, aanroepen naar ongedefinieerde of verouderde functies, bijvoorbeeld om ontwikkelaars te helpen het sneller te repareren en bugs te verminderen voordat ze worden uitgevoerd.
Linters zijn geëvolueerd
Linters zijn geëvolueerd. Ze begonnen met die eenvoudige controles, maar tegenwoordig worden ze steeds geavanceerder. Ze voeren statische analyses uit, dwingen configuratievlaggen af, controleren of een bepaalde stijlgids of beveiligingsregel wordt nageleefd, en nog veel meer.,
laten we een aantal van deze controles onderzoeken en hoe ze nuttig voor u kunnen zijn.
statische analyse
statische analyse betekent dat geautomatiseerde software door uw codebron loopt zonder deze uit te voeren. Het controleert statisch op potentiële bugs, geheugenlekken en elke andere controle die nuttig kan zijn.
Als u een Python ontwikkelaar bent, kent u Radon misschien al. Het kan de bronregels van code (SLOC), commentaarregels, een lege regel en andere ruwe metrics tellen, maar ook, het kan een “Maintainability Index berekenen,” die erg belangrijk kan zijn in sommige projecten.
dat is slechts een voorbeeld., Er zijn tal van andere linters die statische analyses uitvoeren.
gratis E-book: Klik hier om de gratis e-book decodering Code Review en Pull Requests te downloaden. Krijg alle belangrijke punten en best practices om een code review cultuur te implementeren.
Code standardizing
van https://xkcd.com/1285/
het standaardiseren van uw code is een geweldige manier om de conversatie naar een productiever niveau., Het hebben van een richtlijn en het draaien van linters tegen de codebase vermijdt esthetische veranderingen in je pull request, zoals het vervangen van alle tabs voor spaties, het inspringen van een variabele toewijzing, of zelfs regeleinden na een bepaald aantal tekens.
Het Maximaliseren van betekenisvolle wijzigingen brengt uw discussie naar onderwerpen die ertoe doen, zoals architecturale beslissingen, beveiligingsproblemen of potentiële bugs.
tussen haakjes, beveiligingsproblemen en potentiële bugs kunnen ook vermeden worden door linters!
beveiligingsproblemen
Als u van Rails houdt, heeft u waarschijnlijk gehoord van Brakeman., Het is een statische analyse beveiligingshulpmiddel. Het is nuttig om potentiële beveiligingsproblemen te vinden. Bijvoorbeeld, het voert controles uit op zoek naar SQL injectie bij het gebruik van ActiveRecord ‘ s #find_or_create_by en vrienden. Het voegt ook controles voor XSS, config opties, en nog veel meer.
Ruby is niet de enige taal met dit soort engine. SourceLevel ondersteunt veel motoren voor verschillende talen. Inclusief Brakeman.
potentiële bugs
JavaScript heeft enkele trucs. Een van de bekendste is het verschil tussen == en ===., Het is een goede gewoonte, en het vermijdt veel debugging tijd, om altijd ===te gebruiken. Als u bijvoorbeeld eslint inschakelt om dat te controleren, kan het u vertellen welk deel van uw code == gebruikt en het zelfs voor u vervangen.
prestatieverbeteringen
elke ervaren ontwikkelaar kent niet alleen het belang van het uitvoeren van software, maar ook vele trucs die het verbeteren. Het probleem is: hoe zit het met nieuwkomers? Hoe kun je deze kennis doorgeven? Zelfs senior programmeurs kunnen een techniek of twee missen. Dus, waarom niet laat een automatiseringssoftware het voor u doen?,
Wist u dat in CSS De universele selector ( * ) de laadtijd van pagina ‘ s kan vertragen? Of dat niet-gekwalificeerde attribuutkiezers dezelfde prestatiekenmerken hebben als de universele selector? Ze vermijden is een goede praktijk.
veel linters bevatten een prestatiecontrole. Ze kunnen verschillende soorten prestatieverbeteringen toevoegen voor ervaren en nieuwkomers ontwikkelaars. CSSLint is slechts een voorbeeld.
en vele andere aspecten
tot in het oneindige en verder!, Er zijn heel veel linters voor verschillende programmeertalen, configuratiebestanden en zelfs voor software-integraties. Elke controle die ertoe doet en geautomatiseerd kan worden, kan veranderen in een linter.
Als u in een bepaald scenario werkt, moet u mogelijk uw linter schrijven, ook al is dit niet erg waarschijnlijk in onze branche. Controles voor HTML toegankelijkheidsfuncties, internalisatie potentiële fouten, grammatica fouten, en vele anderen zijn er al, open-source, wachten op u om te downloaden, configureren, en beginnen te gebruiken.
voordelen van linting
volgens Ferit T.,, linting verbetert de leesbaarheid, verwijdert domme fouten voor uitvoering en code beoordeling. Maar, zoals gezegd, linting kan meer complexe taken doen, zoals het detecteren van code geuren of het uitvoeren van statische analyse van uw codebase.
maar wat zijn in de praktijk de voordelen van linting?
het verbetert het discussieniveau voor codebeoordeling
als je Pull Request geen typefouten, noch ongebruikte variabelen heeft, en voldoet aan de stijlgids, heeft het gesprek de neiging om zich te concentreren op het architectuurstandpunt. Dat is het., Pull Request is een geweldige plek om te wijzen op prestatieproblemen, kwetsbaarheden in effecten, of suggereren betere abstracties. Je hoeft niet te krijgen in die enkele of dubbele aanhalingstekens of tabblad vs. spaties discussie. Het is zeker een productiviteitswinst.
laat code eruit zien als geschreven door een enkele persoon
op de middellange en lange termijn het hebben van een betrouwbare codebasis die eruit ziet als geschreven door dezelfde persoon is uitstekend. Onderhoudbaarheid en evolutie zijn gemakkelijker omdat iedereen de neiging heeft om sneller en nauwkeuriger te begrijpen wat er geschreven wordt., Het voorkomt bugs, maakt het werk meer vreugdevol voor ontwikkelaars, en versnelt de time to market van nieuwe functies.
geeft zicht op de gezondheid van uw codebase
Is uw code gezond? Dat Weet je pas als je het meet. Een spannende manier om dit te doen is het toevoegen van een stap in uw CI/CD pijplijn om de evolutie van uw code status te meten. Beter dan dat, kunt u zo snel mogelijk actie ondernemen als je ziet dat de gezondheid ervan bederft., Dergelijke acties kunnen impliceren op het maken van technische debetkaarten in uw board of zelfs het probleem tijdens uw agile retrospective of architectuur commissie vergadering.
verspreidt bewustzijn en eigendom over de kwaliteit van de code
ervaren ontwikkelaars kunnen een verschil bekijken en relevante problemen over de voorgestelde wijziging aan de orde stellen. Ze weten waarschijnlijk waar te zoeken: zijn variabelen namen descriptives? Hoeveel regels heeft een methode nodig? Is er een superklasse?
maar hoe zit het met nieuwkomers? De kennis in een team is vaak heterogeen. Het betekent dat niet elke ontwikkelaar weet wat te kijken over de code., Het hebben van een linter om automatisch te vertellen waar code geuren zijn, is een uitstekende manier om deze kennis te verspreiden en het team verantwoordelijk te maken voor de veranderingen.
kwaliteit is geen individuele verantwoordelijkheid. Het is essentieel om de kwaliteit van de code na verloop van tijd te meten en te controleren. Anders wordt de code rommelig, wat de ontwikkeling en de time-to-market vertraagt.,
controleert technische schulden
aangezien veel moderne linters zoeken naar mogelijke technische schulden, zoals code smells, style guide mismatches, of slecht ontworpen code (diepe ketens vanif statements, of te complexe methoden, bijvoorbeeld), correleert linters met technische schulden.
het expliciet maken van technische schulden tijdens het codebeoordelingsproces help softwareontwikkelaars of ingenieurs om het te spotten, te bespreken en op te lossen voor de merge in de master branch. Het is een zeer handige praktijk die de technische schuld inserties controleert.,
Automatiseer uw Code Review: SourceLevel ondersteunt +30 linters om u te helpen de kwaliteit van de code te verbeteren. Klik hier om een demo te bekijken of een gratis proefperiode te starten.
voorbeelden van linters
Er zijn een groot aantal linters. Afhankelijk van de programmeertaal zijn er zelfs meer dan één linters per taak. Voor de go-programmeertaal zijn er bijvoorbeeld ktlint en detekt. Beiden doen hetzelfde. Hetzelfde gebeurt met eslint, een linter ontworpen voor JavaScript. Het werkt zeer vergelijkbaar met tslint of jshint.,
Linters gericht op Beveiliging
- Brakeman voor Ruby
- Bandit voor Python
- Node beveiliging voor JavaScript
Linters gericht op de stijlgids en coderingsconventies
- CSSLint., SCSS Lint en Sass Lint voor Cascading Style Sheet
- Gofmt voor Go-taal
- Swiftlint voor Switft
- rustfmt voor Roest
- Credo voor Elixir
Linters voor Statische Analyse
- pep8 voor Python
- Phan of PHP Puinhoop Detector voor PHP
- kibit voor Clojure, ClojureScript, cljx, en andere Clojure varianten.
- PMD voor Java
conclusie
Linters helpen u productiever te worden en besparen u tijd en geld. Ze drijven uw team naar betere beslissingen (die gericht zijn op data) en delen eigendom over de kwaliteit.,
Op SourceLevel ondersteunen we veel linters. Ze draaien tegen elke pull request open en reageren op de juiste regel en bestanden de gevonden problemen. Het verhoogt de productiviteit en effectiviteit van ontwikkelaars.
we noemen het automatisering van code review. Elke repository kan zijn configuratie bestand hebben en vervolgens pull requests laten beoordelen volgens de gekozen style-guide regels.