Noen tid siden jeg hjelpe en junior utvikleren, som har et åpenbart problem på ham-koden for å finne ut hva som var galt på det. Han installert en lo og lastet ned (gud vet hvorfor) en egendefinerte ordlisten for det. Jeg laget en liten test miljø og viste ham at forskjellen mellom ulike tester, på forskjellige steder og noen begrensninger av hver (på denne lille miljø).
Nylig snakket jeg om å teste med en kollega og jeg husket denne anekdoten og sa til meg selv til å skrive et innlegg om det som det kunne være interessant for mange.,
Hva er linting?
Linting er automatisert kontroll av kildekoden for programmatiske og stilistiske feil. Dette er gjort ved hjelp av en lo-verktøyet (en.k.a. linter). En lo-verktøyet er en enkel statisk kode analysator.
begrepet linting kommer opprinnelig fra en Unix-verktøy for C. Det er mange koden linters tilgjengelig for ulike programmeringsspråk i dag.
Lo-programmering er en type automatisert sjekk. Det kan skje tidlig i utviklingen, før koden anmeldelser og testing. Det er fordi automatisert kode sjekker gjøre koden gjennomgang og test prosesser mer effektive., Og de frie din utviklere å fokusere på de riktige tingene.
Mange automatisert testing verktøy dra nytte av en innebygd linter å kaste feil, angi noen poengsum om koden kvalitet og blokkere lage eller distribuere nivå hvis dette resultatet er lavere enn ønsket (automatisk eller stoppe prosessen å kaste et varsel for å sjekke manuelt om dette «feil» skal lappes eller ikke).
Hva er ment for?
Linting er beregnet for å redusere feil og forbedre den generelle kvaliteten på devs kode, akselerere utvikling og redusere kostnadene ved å finne feil tidligere.,
Ved å bruke Lo-programvare?
Hvis dette er nytt for deg, du kan være noen litt hyped med lints på dette punktet, men de er ikke en programagically verktøyet. En lo er rett og slett en «scrapper»/fil-leser manus med en fil (vanligvis en json eller xml) med forhåndsdefinerte (eller tilpasses) regler om hvordan koden må se ut. Faktisk IDEs har en innebygd Lo som vil kaste deg en feil (dvs. hvis du ringer til en ikke-eksisterende metode, eller hvis du prøver å legge til en string value inn en heltallsvariabel) eller en advarsel (dvs., hvis du deklarerer en variabel inne i en betinget og så kommer du tilbake som variabel på slutten av metode). Men jeg snakker ikke om den innebygde kode lo, som denne linters er «myk» og ettergivende, ellers er mange mennesker som ikke kommer til å bruke de IDEs, vil vi se hvorfor senere.
Du kan bruke en bestemt Lo hvis du passer inn i dette utsagn:
Når Du Bruker Tolket programmeringsspråk.
Noen språk er bedre egnet for kode linting enn andre. PHP, Python og JavaScript er tolket språk, betyr dette at de mangler en sammenstilling fase*., Så ved hjelp av lo-programvare er effektive for å sikre konsistent koding stil og løse grunnleggende koding feil i disse tilfellene.
Men, når det kommer til kompilert språk, slik som C og C++, ved hjelp av lo-programvaren kan ikke være nok. C og C++ er komplekse og kan kreve mer avansert kode analyse.
*Du kan bli uutholdelig jeg kompilere JavaScript! men det er faktisk ikke sant. I dag på front end vi bruker verktøy som bundlers, legge til noen javascript-verktøy som passerer våre js av noen faser slik som minify, ugglify, ofuscate. Noen av disse verktøyene også slette ubrukte koden på sin produksjon., Men ingen av denne ting betyr at du er kompilering javascript, som utgang vil være en .js-fil likevel; ingen bytekode, ingen assembler.
Det er sant at du kan konvertere javascript i web-forsamlingen, men det er ikke en direkte bane fra én til en annen, må du konvertere din js inn i noe «komplisert» som for C-kode, og deretter kompilere den inn i web-montering.
Når Du Bruker Standard Regler
Dette er litt vanskelig uttalelse., På et programmeringsspråk som du ikke vil være i stand til å bruke noe som ikke er bygget på programmeringsspråk (det er ikke sant i det hele tatt, som du kan legge til biblioteker eller kaste system kommandoer fra programmeringsspråk, men allikevel Lo har ingenting å gjøre med det slik…)
Hva vanlige Reglene stå for?
ved Hjelp av et rammeverk vil passe fint her, må du bruke et rammeverk for innebygde metoder for å nå ønsket resultat.
noen Ganger standard regler betyr moteriktig kode., Denne metoder og løsninger som samfunnet gjentar som et mantra til de finner en annen moteriktig måte å nå målet på en gitt oppgave, eller til noen med offentlig ettervirkning forteller samfunnet «hei, jeg var å analysere disse løsningene, og jeg finner at det er en bedre måte for å nå dette for denne årsaker», og da samfunnet beveger seg på.
Når du Har Behov for Grunnleggende
Lo verktøy er stor for grunnleggende analyse. Men hvis du trenger mer sofistikerte analyser må du lete andre steder (automatisert testing verktøy og test-drevet utvikling).
Hvor skal jeg se en lo?
1., På automatiserte tester (vi kaller dem automatisert fordi de kjører automatisk, men noen har behov for å kode test for hvert use case på en app) som Cypress, kan du legge til en lo til å score koden kvalitet.
Dette kan kjøre på utviklingen tid (når dev treff på test-knappen) eller sannsynlig på distribuere scenen. For eksempel, når du presse noe inn i master gren det kan være en trigger til å heve tester, inkludert lo, og blokkere distribuere (og klandre deg) hvis du gjorde noe galt, så vil du trenger å reparere eller finne feilen (dette betyr ikke at det er din skyld., Jeg kunne presse et API som gjør din klient crash mottar uventede verdier, og dette vil være min feil, ikke din).
Denne testen er ikke ment å skylde på deg, men å hjelpe inn i utviklingsprosessen, er det vanligvis bedre å finne en bug før å integrere inn i pre-produksjon scenen på grunn av en test feil enn å finne det ved overraskelse i produksjon.
2. På store prosjekter, som regel på store selskaper., Hvis du er på et veldig stort selskap prosjektleder skal som all koden ser ut som den samme (formatering) slik at de sannsynligvis har en lo for er det et sted det punktet du hvis du har lagt til 4 hvite områder til å rykke noe de vil med 2, og som vil klandre deg hvis du ikke deklarere en metode med kamel tilfelle for eksempel.,
jeg finner toner av junior utviklere prøver å kjempe mot det, fordi de liker noen bestemt formatering, men uten at dette verktøy, denne store programvare apps vil se ut som en frankensteins monster på en fremtidig øker vanskelighetsgraden på å lese alle deler eller følge noen metode stier og klasse overstyrer. Tenk på det som å lese en bok på hvor hvert ledd har en annen font-størrelse, font-family og så.
Hvor å ikke bruke det?
Dette punktet er så enkelt: du må ikke bruke den på en dynamisk kontekst, og på ikke-programmeringsspråk.
1. Den første er lett å forstå., Hvis du er på en dynamisk kontekst lo (en statisk checker) vil aldri vite det endelige resultatet, og vil klandre deg for ting som er OK, jeg skal legge noen eksempel på neste punkt.
2. Dette bør høres latterlig, redundant eller du kan fortelle meg «Der du bruker en lo om det ikke er på et programmeringsspråk?»
Mulder, det er HTML-og CSS-linters ut det.
Ja.. um… Men, hvordan?,
Vel, de er ikke linters i sannhet, de er bare kode-brikker, det samme kan du gjøre med w3cs validator, men i stedet på å kopiere koden inn i en validator, de vanligvis kjører på utvikling gang med å beskylde deg for ulike ting basert på vekke mening, noe som er irriterende, unøyaktig, og egentlig ikke passer i dag bruk av disse to teknologiene (eller tre hvis du vil legge til SCSS), og viktigst av alt, de vanligvis ikke har en grunn for hvert utsagn, eller årsaker avviker fra et punkt til et annet, eller grunnen er utdatert, eller årsakene er ikke aktuelt for alle prosjekter., Det er derfor du vil finne tonene av «Glemme CSSLint, det er sta og ikke passer prosjektet» kommentarer og mange lignende andre over internett.
Du kan finne noen deler av koden som er kalt Linters for noen grunn, men minst de fortelle deg «jeg’ am en sta kode formatter» som denne .,
HTML-lo kan være nyttig noen ganger som det vil tvinge deg til å legge til en alt-attributtet til bilder og andre tilgjengelighet og god praksis (Mest IDEs viser du en advarsel om det også uten å legge inn en lo, som er bedre) men dette vil ikke hindre deg fra å bruke en <span> som <p> eller annen dårlig html-bruk.
Det vil også irritere deg hvis du skriver mal komponenter med dumme utsagn som «du har ikke doctype-erklæringen, du har ikke html, head, tittel eller body-taggen., Og du kan ting «selvfølgelig, som denne filen vil bli lastet inn i et dokument som allerede har denne tags», men HTML-lo kan ikke vite det, Lints er statisk brikker, og du arbeider på et dynamisk miljø, så gå videre og slett html lo i det hele tatt.
CSSLint er litt annerledes, det er ingen ting du kan lo her uansett, kan du skrive gyldig eller ugyldig CSS, men det er alt.,
Det er god praksis på CSS som står for effektivitet og hastighet formål (det vil også komme til å UX), andre som skal gå til vedlikehold, skalerbarhet og lesbarhet formål (vanligvis basert på erfaring med utviklingsarbeid), enda de står for tilgjengelighet (basert på UI/UX-studier og nettleser gjengivelser, skjermkontrasten tester og så). Men det er ingen vits på å kombinere det hele inn i en linter og forteller devs for å matche alle disse praksis, først og fremst fordi det er motsetninger som trenger et menneske til å gjøre beslutningen om å bruke en eller annen.,
Et eksempel på bruk hvor å velge kan behandles av det faktum at å legge til alle tilgjengelighet CSS-kode vil observably øke størrelse, legge i gang, og første gang interaktiv beregninger slik at du vanligvis vil velge bare de tilgjengelighet regler som passer best til dine kunder og samtidig opprettholde god ytelse.
For å stille et dumt eksempel om en sta regel på CSSLint la oss si at jeg vil ha en linear-gradient som bakgrunn på min hjemmeside viktigste blokk. CSSLint vil kaste en advarsel om linear-gradient ytelse.,
På dette punktet CSSLint ønsker du å slette linear-gradient, men hva er alternativene?
ved Hjelp av et bilde vil være toner av ganger mindre effektive for å nå målet design (og også vil redusere den visuelle kvaliteten av fargeovergangen, og vil gjøre det vanskeligere å endre størrelse for å passe alle mulig størrelser av-blokk).
Så hva kan vi gjøre? Bare ignorere CSSLint, fordi det er sta og dette støttes ikke av noen annen grunn.
Det er en forskjell på å legge til en linear-gradient vs legge til 42342 lineær-gradienter på samme vis., Forresten, hvis du trenger dem, vil det fortsatt være mer effektivt enn å bruke bilder.
Du kan også finne motstridende uttalelser på det slik:
«ikke bruker-Id-er for styling». Grunnen er at det vil være en ikke gjenbrukbare regelen.
og
«ikke bruk tilstøtende klasser». Jeg kunne ikke riktig finne ut årsaken uten å lese css lo regler forklaring og grunn er», Selv om det teknisk tillatt i CSS, disse er ikke behandlet på riktig måte i Internet Explorer 6 og eldre».
jeg har noe å fortelle deg CSSLint., Ingen bryr seg om IE 6 og tidligere, er vi i 2020, 99% av web-programvare støtter I. E. 11 så mye, som ble utgitt på 2013 av veien og har mindre enn 3% bruk.
Etter den annen side, hvor det for Guds skyld, det er uttrykk for at alle CSS-reglene har til å være gjenbrukbare på samme vis?
Hvis du har et unikt element på din web app, dvs. du har sannsynligvis bare en navbar, bare en chat popup hvis noen, bare en navbar logo og bare en bunntekst for å navngi noen, hvorfor trenger du å legge til det er styling global? Er ikke det en dårlig praksis som er i motsetning til alle andre språk rundt om i verden?,
Som et tillegg, la oss si at du har 5 synspunkter på prosjektet. Hvis du har en <nav> det vil være sannsynlig vises på alle av dem, slik at de samme styling du sette under #primary-navigation fungerer på 5 forskjellige visninger. Er ikke dette en måte å re-brukervennlighet?
for Å øke dumhet rundt at både regler, se hvordan det lar deg på en vanskelig situasjon.,
Hvis du ikke kan bruke en id for styling <nav class="dark-theme">, og du kan ikke legge til tilstøtende klasser<nav class="primary-navigation dark-theme">, hvordan du skal klare å omfang din styling og gjør det mer stabile, lesbar og hvordan klarer du det for å legge java-script event lyttere når det er behov for på en effektiv måte?
Du kan ganske enkelt ikke.
Hva kan vi gjøre semantisk korrekt og lett å vedlikeholde?, La oss sette et eksempel:
Her er en annen uttalelse som får meg til å le en stund:
Unngå ukvalifisert attributt-velgere «Ukvalifisert attributt-velgere, for eksempel , er i samsvar med alle elementene først, og deretter se deres attributter. Dette betyr at ukvalifisert attributt-velgere har de samme egenskapene som den universelle selector (*)»
Min kjære, dette er ikke forskjellig fra hva som skjer når du bruker en klasse, eller id-tag-velgeren.
stadier av nettleseren CSS-rendering er:
- Bygning DOM., DOM er et tre-lignende struktur data som inneholder alle HTML-noder på siden. Hver node inneholder data om at HTML-element (for eksempel attributter, id-ene, og klasser) Hvis noden har alle HTML-elementer som barn, det vil også peke på de barn noder.
- Bygge CSSOM. Når leseren møter en CSS-stilark (enten innebygd eller eksternt), er det behov for å analysere teksten inn i noe de kan bruke for stil oppsett og maling. Data struktur for at nettleseren viser CSS inn er kreativt kalt CSSOM.
- for å Generere en Render Treet., Kort sagt, gjengi treet inneholder all informasjon som er nødvendig for leseren å lage punkter på siden. Nettleseren i utgangspunktet tar DOM og CSSOM og klemmer dem sammen, for å fjerne alt som ikke vil ha en effekt på gjengitt utgang.
- Layout og Maleri.
på Layout fase, nettleseren tall ut størrelse og plassering av elementer (ikke gjengitt ennå), og deretter, på maling trinn det begynne å generere punkter som vi vil se.,
Som du kan se kan du få et lite performance bias når hekkende ukritisk din velgere, som body>#main-content>.first-block .products-card p som du vil generere unødvendig barn noder i CSSOM som trenger å matche DOM, og dette vil ta litt mer tid enn å bruke bare en.products-card p, men som vi trenger for å opprettholde denne koden og sannsynligvis skala det, vi må omfanget reglene så la oss si #main-content .products-card p.
Det er en god praksis, men jeg har aldri sett en web-app som mer spesifikke velgere forårsaker legg hastighet flaskehals., Dette er vanligvis forårsaket av iterating over og over igjen å holde toner av ubrukt kode som leseren vil legge inn CSSOM og vil trenge å sammenligne med DOM for å finne ut om det er OK å legge det inn i gjengi treet eller ikke.
For dette, og mange andre grunner er grunnen til at du kan finne artikler som forklarer hver feil punkt på CSSLint som dette som forklarer ting på en mer omfattende måte enn jeg gjorde her.
Oppsummering
Linters er bra for noen ting og dårlig for andre.,
De kan også bli redigert for å passe noen prosjektet behov, eller noen person eller selskap preferanser for å unngå disse reglene som er sta og legge til andre verdifulle regler som passer inn i det prosjektet du er i.
Det er mange grunner til å bruke linters på tolket språk (på samlet seg, IDE-og kompilatoren vil ta seg av dette, men du kan også legge til en Lo til å sjekke kode formatering eller bare for å få advarsler før kompilere for å unngå å vente til kompilatoren finner en feil eller slutter å vite om alt er OK).,
Det er mange grunner til å legge linters til HTML (bare tilgjengelighet formål kan være nyttig, tror jeg) og det er færre grunner for å legge til linters på CSS (som kan reduseres til en kode en formatering checker).
Har du brukt en Lo? Hvis så, fortell oss hvilket språk og kontekst, og hva var din opplevelse.
jeg personlig likte det etter noen tweaks når du bruker maskinskrevet kopi.
Som alltid, håper du liker dette innlegget og beste hilsen,
Joel