Flere og flere hold har vedtaget linters og andre statiske værktøjer i deres udviklingsproces. Nogle integrerede dem i ideen om deres præference, andre automatiserede ved at køre dem som et ekstra trin i deres CI. Også, nogle kører begge veje.
Hvad er en linter, så?
ifølge diikipedia er linter
et værktøj, der analyserer kildekode for at markere programmeringsfejl, bugs, stilistiske fejl og mistænkelige konstruktioner.,
den første linter blev skrevet af Stephen C. Johnson i 1978, mens han arbejdede i Uni. – operativsystemet på Bell Labs. Efter at mange andre linters har optrådt til forskellige formål og sprog, ikke kun C.
Den første linters anvendes til at kontrollere kildekoden og finde potentielle optimeringer for udarbejdelsen. Men i årenes løb vil mange andre kontroller og analyser blive inkluderet i linting-processen.
brugen af linters har også hjulpet mange udviklere til at skrive bedre kode til ikke kompilerede programmeringssprog., Da der ikke er kompilering tidsfejl, finde stavefejl, syntaksfejl, anvendelser af sort variabler, opkald til udefinerede eller forældede funktioner, for eksempel, hjælpe udviklere til at løse det hurtigere og reducere fejl før udførelse.
Linters har udviklet sig
Linters har udviklet sig. De startede med disse enkle checks, men i dag bliver de mere og mere sofistikerede. De udfører statisk analyse, håndhæver konfigurationsflag, kontrollerer overholdelse af en given stilguide eller sikkerhedsregel og meget mere.,
lad os undersøge nogle af disse kontroller, og hvordan de kan være nyttige for dig.
statisk analyse
statisk analyse betyder, at automatiseret soft .are kører gennem din kodekilde uden at udføre den. Det kontrollerer statisk for potentielle fejl, hukommelseslækager og enhver anden kontrol, der kan være nyttig.
Hvis du er en Python-Udvikler, kender du muligvis allerede Radon. Det kan tælle kildelinjerne med kode( SLOC), kommentarlinjer, en tom linje og andre rå målinger, men det kan også beregne et “Vedligeholdelsesindeks”, hvilket kan være meget vigtigt i nogle projekter.
det er bare et eksempel., Der er masser af andre linters, der udfører statisk Analysekontrol.
Gratis E-bog: Klik her for at hente den gratis e-bog Afkodning af Kode Gennemgang og Trække Anmodninger. Få alle de vigtigste punkter og bedste praksis for at gennemføre en kode gennemgang kultur.
Kode standardisering
https://xkcd.com/1285/
Standardisering din kode er en fantastisk måde at flytte samtalen til en mere produktive niveau., At have en retningslinje og køre linters mod kodebasen undgår æstetiske ændringer i din pull-anmodning, som at erstatte alle faner for mellemrum, indrykke en variabel tildeling eller endda linjeskift efter et givet antal tegn.maksimering af meningsfulde ændringer tager din diskussion til emner, der betyder noget, som arkitektoniske beslutninger, sikkerhedsproblemer eller potentielle fejl.af den måde, sikkerhedsproblemer og potentielle fejl også kan undgås ved linters!
sikkerhedsproblemer
Hvis du er i Rails, har du sikkert hørt om Brakeman., Det er en statisk analyse sikkerhedsværktøj. Det er gavnligt at finde potentielle sikkerhedsproblemer. For eksempel kører det kontrol på udkig efter S .l-injektion, når du bruger ActiveRecord ‘ s #find_or_create_by og venner. Det tilføjer også kontrol for optionsss, config muligheder, og meget mere.Ruby er ikke det eneste sprog med denne type motor. SourceLevel understøtter masser af motorer til forskellige sprog. Brakeman inkluderet.
potentielle bugs
JavaScript har nogle tricks. En af de mest berømte er forskellen mellem == og ===., Det er en god praksis, og det undgår meget debugging tid, at altid bruge ===. Hvis du for eksempel aktiverer ESLint for at kontrollere det, kan det fortælle dig, hvilken del af din kode der bruger == og endda erstatte den for dig.
ydelsesforbedringer
hver erfaren udvikler kender ikke kun vigtigheden af at udføre soft .are, men mange tricks, der forbedrer det. Problemet er: hvad med nyankomne? Hvordan kan du videregive denne viden fremad? Selv seniorprogrammører kan gå glip af en teknik eller to. Så hvorfor ikke lade en automatiseringssoft ?are gøre det for dig?,
vidste du, at i CSS kan universal selector (*) sænke en sideindlæsningstid? Eller at ukvalificerede attributvælgere har de samme ydeevneegenskaber som universalvælgeren? At undgå dem er god praksis.
mange linters omfatter en performance check. De kan tilføje forskellige former for forbedringer af ydeevnen for erfarne og nytilkomne udviklere. CSSLint er blot et eksempel.
og mange andre aspekter
til uendelig og videre!, Der er masser af linters til forskellige programmeringssprog, konfigurationsfiler og endda til soft .areintegrationer. Enhver kontrol, der betyder noget og kan automatiseres, kan blive til en linter.
Hvis du arbejder i et bestemt scenario, skal du muligvis skrive din linter, selvom det ikke er for sandsynligt i vores branche. Checks for HTML tilgængelighedsfunktioner, internalisering potentielle fejl, grammatik fejl, og mange andre er allerede der, open-sourced, venter på at do .nloade, konfigurere og begynde at bruge.
fordele ved linting
ifølge Ferit T.,, linting forbedrer læsbarheden, fjerner dumme fejl før udførelse og kode gennemgang. Men som nævnt kan linting muligvis gøre mere komplekse job, som at opdage kodelugt eller udføre statisk analyse af din kodebase.
men i praksis, hvad er fordelene ved linting?
det forbedrer diskussionsniveauet for kodegennemgang
Hvis din Pull-anmodning ikke har skrivefejl eller ubrugte variabler og er i overensstemmelse med stilguiden, har samtalen en tendens til at fokusere på arkitekturens synspunkt. Sådan., Pull re .uest er et godt sted at pege på præstationsproblemer, værdipapirsårbarheder eller foreslå bedre abstraktioner. Du behøver ikke at komme i at enkelt eller dobbelt citater eller fane vs. mellemrum diskussion. Det er en produktivitetsgevinst for sikker.
gør kode ligne skrevet af en enkelt person
til mellemlang og lang sigt at have en pålidelig kodebase, der ligner skrevet af den samme person er fremragende. Vedligeholdelse og evolution er lettere, fordi alle har en tendens til at forstå, hvad der er skrevet hurtigere og mere præcist., Det forhindrer fejl, gør jobbet mere glædeligt for udviklere, og fremskynder tiden til markedet for nye funktioner.
giver synlighed af din kodebase sundhed
er din kode sund? Du ved det ikke, før du måler det. En spændende måde at gøre det på er at tilføje et trin i din CI/CD-pipeline for at måle udviklingen i din kode sundhedsstatus. Bedre end det, kan du gribe ind så hurtigt som muligt, når du ser dens helbred til forfald., Sådanne handlinger kan indebære at oprette tekniske betalingskort i dit bord eller endda rejse spørgsmålet under dit agile retrospektive eller arkitekturudvalgsmøde.
spreder opmærksomhed og ejerskab over kodekvalitet
erfarne udviklere kan undersøge en diff og rejse relevante spørgsmål om den foreslåede ændring. De ved sikkert, hvor de skal se: er variabler navne beskrivelser? Hvor mange linjer tager en metode? Er der nogen superklasse?
men hvad med nyankomne? Viden i et team er ofte heterogen. Det betyder, at ikke alle udviklere ved, hvad de skal kigge over koden., At have en linter til at fortælle, hvor kode lugt er automatisk, er en glimrende måde at sprede denne viden på og gøre teamet ansvarligt for ændringerne.
kvalitet er ikke en enkeltperson ansvar. Det er vigtigt at måle og kontrollere kodekvalitet over tid. Ellers bliver koden rodet, hvilket bremser udviklingen og time to market.,
Kontrol teknisk gæld
Som mange moderne linters kigge efter mulige tekniske gæld, som koden lugter, style guide misforhold, eller dårligt designet kode (dybt kæder af if erklæringer, eller alt for komplicerede metoder, for eksempel), linters korrelerer med teknisk gæld.
at gøre teknisk gæld eksplicit under kodegennemgangsprocessen hjælper soft .areudviklere eller ingeniører med at få øje på, diskutere og rette den, før fusionen tilmaster filial. Det er en meget praktisk praksis, der styrer de tekniske gældsindsættelser.,
Automatiser din Kodeanmeldelse: SourceLevel understøtter +30 linters for at hjælpe dig med at forbedre kodekvaliteten. Klik her for at se en demo eller starte en gratis prøveperiode.
eksempler på linters
Der er et stort antal linters derude. Afhængigt af programmeringssproget er der endda mere end en linters til hvert job. For eksempel, for Go programmeringssprog, der er ktlint og detekt. Begge udfører et lignende job. Det samme sker med eslint, en linter designet til JavaScript. Det virker meget lig tslint eller jshint.,
Linters fokuseret på Sikkerhed
- Brakeman for Ruby
- Bandit til Python
- Node Sikkerhed for JavaScript
Linters fokuseret på style guide og kodning konventioner
- CSSLint., SCSS Fnug og Sass Lint for Cascading Style Sheet
- Gofmt for at Gå sprog
- Swiftlint for Switft
- rustfmt for Rust
- Credo for Elixir
Linters for Statisk Analyse
- pep8 for Python
- Phan eller PHP Rod Detektor for PHP
- kibit for Clojure, ClojureScript, cljx, og andre Clojure varianter.
- PMD til Java
konklusion
Linters hjælper dig med at blive mere produktiv og spare tid og penge. De driver dit team til bedre beslutninger (dem, der er orienteret efter data) og deler ejerskab over kvaliteten.,
på SourceLevel understøtter vi masser af linters. De kører mod hver pull anmodning åben og kommentere den rette linje og fil de fundne problemer. Det øger udviklernes produktivitet og effektivitet.
vi kalder det automatisering af kode anmeldelse. Hver repository kan have sin konfigurationsfil og derefter have pull anmodninger gennemgået i henhold til valgte stil-guide regler.