for nogen tid siden hjælper jeg en junior udvikler, som har et tilsyneladende problem på ham kode, for at finde ud af, hvad der var galt på det. Han installerede en fnug og Do .nloadede (Gud ved hvorfor) en tilpasset ordbog til den. Jeg forberedte et lille testmiljø og viste ham forskellen mellem forskellige tests, på forskellige punkter og nogle begrænsninger af hver (på dette lille miljø).
for nylig talte jeg om at teste med en kollega, og jeg huskede denne anekdote og fortalte mig selv at skrive et indlæg om det, da det kunne være interessant for mange.,
Hvad er linting?
Linting er den automatiske kontrol af din kildekode for programmatiske og stilistiske fejl. Dette gøres ved hjælp af et fnugværktøj (alias linter). Et fnugværktøj er en grundlæggende statisk kodeanalysator.
udtrykket linting stammer oprindeligt fra et uni. – værktøj til C. Der er mange kodelintere tilgængelige for forskellige programmeringssprog i dag.
Lint programmering er en type automatiseret kontrol. Det kan ske tidligt i udviklingen, før kode anmeldelser og test. Det skyldes, at automatiserede kodekontroller gør kodevurderings-og testprocesserne mere effektive., Og de frigør dine udviklere til at fokusere på de rigtige ting.
Mange automatiserede testværktøjer drage fordel af en indbygget linter at kaste fejl, der er nogle score om koden kvalitet og blokere kompilering eller installere trin, hvis dette resultat er lavere end den ønskede (automatisk eller afbryd processen smide en anmeldelse til manuelt at tjekke, om denne “fejl” bør repareres eller ikke).
hvad er beregnet til?
Linting er beregnet til at reducere fejl og forbedre den samlede kvalitet af devs kode, fremskynde udviklingen og reducere omkostningerne ved at finde fejl tidligere.,
Hvornår skal du bruge Lint-soft ?are?
Hvis dette er nyt for dig, kan du være lidt hyped med lints på dette tidspunkt, men de er ikke et programagisk værktøj. En fnug er simpelthen en”scrapper” /file reader script med en fil (normalt en json eller JML) med foruddefinerede (eller tilpassede) regler om, hvordan koden skal se ud. Faktisk har ide ‘ er en indbygget Lint, der vil kaste dig en fejl (dvs. hvis du kalder en ikke-eksisterende metode, eller hvis du forsøger at tilføje en strengværdi til en heltalsvariabel) eller en advarsel (dvs ., hvis du erklærer en variabel inde i en betinget, og derefter returnerer du denne variabel i slutningen af din metode). Men jeg taler ikke om den indbyggede kodelint, da disse linters er “bløde” og tilladte, ellers vil mange mennesker ikke bruge disse ide ‘ er, vi vil se hvorfor senere.
Du kan bruge en bestemt fnug, hvis du passer ind i disse udsagn:
Når du bruger fortolkede programmeringssprog.
Nogle sprog er bedre egnet til kodelyngning end andre. PHP, Python og JavaScript fortolkes sprog, det betyder, at de mangler en kompilering fase*., Så ved hjælp af lint soft .are er effektiv til at sikre ensartet kodning stil og løse grundlæggende kodning fejl i disse tilfælde.men når det kommer til kompilerede sprog, såsom C og C++, er det måske ikke nok at bruge lint-soft .are. C og C++ er komplekse og kan kræve mere avanceret kode analyse.
*Du kan råbe Jeg kompilere JavaScript! men det er faktisk ikke sandt. I dag på frontend vi bruger værktøjer som bundlers, tilføje nogle javascript værktøjer, der passerer vores js ved nogle faser såsom minify, ugglify, ofuscate. Nogle af disse værktøjer sletter også ubrugt kode på dens output., Men ingen af disse ting betyder, at du kompilerer javascript, da output vil være en .js fil alligevel; ingen bytekode, ingen assembler.
Det er sandt, at du kan konvertere javascript i web-samling, men det er ikke en direkte vej fra den ene til den anden; du skal konvertere din js til noget “kunne oversættes” sådan C-kode og derefter samle det i web-forsamling.
Når du bruger standardregler
er dette en smule vanskelig erklæring., På et programmeringssprog kan du ikke bruge noget, der ikke er indbygget på dit programmeringssprog (det er slet ikke sandt, da du kan tilføje biblioteker eller kaste systemkommandoer fra programmeringssprog, men alligevel har Lint intet at gøre med det…)
hvilke standardregler står for?
ved hjælp af en ramme vil passe rart her, skal du bruge rammer indbyggede metoder til at nå det ønskede output.nogle gange betyder standardregler fashionabelt kode., Denne metoder og løsninger, som fællesskabet gentages som et mantra, indtil de finder et andet moderigtigt måde at nå målet om en given opgave, eller til en person med offentlige eftervirkning fortæller fællesskabet “hey, jeg var analysere dette løsninger, og jeg finder, at der er en bedre måde at nå ud til denne årsager” og derefter fællesskabet bevæger sig på.
Når dine behov er grundlæggende
Lintværktøjer er gode til grundlæggende analyse. Men hvis du har brug for mere sofistikeret analyse, skal du søge andre steder (automatiserede testværktøjer og testdrevet udvikling).
hvor skal jeg se en fnug?
1., På automatiserede tests (vi kalder dem automatiserede, fordi de kører automatisk, men nogen skal kode testen for hver brugssag på en app) som Cypress, kan du tilføje en lint for at score kodekvaliteten.
dette kan køre på udviklingstid (når dev rammer testknappen) eller sandsynligvis på implementeringsfasen. For eksempel, når du skubber noget ind i master branch, kan det være en trigger til at hæve testene, inklusive fnug, og blokere deploy (og bebrejde dig) hvis du gjorde noget forkert, skal du reparere eller finde fejlen (dette betyder ikke, at det er din skyld., Jeg kunne skubbe en API, der gør din klient nedbrud modtager uventede værdier, og dette vil være min skyld, ikke din).
disse tests er ikke beregnet til at bebrejde dig, men for at hjælpe med udviklingsprocessen er det normalt bedre at finde en fejl, før de integreres i forproduktionsfasen på grund af en testfejl end at finde den overraskende i produktionen.
2. På store projekter, normalt på store virksomheder., Hvis du er på et meget stort firma, skal projektlederen gerne have, at al koden ser ud som den samme (formatering), så de sandsynligvis har en fnug til det et sted, der peger dig, hvis du tilføjede 4 hvide mellemrum til at indrykke noget, de vil have med 2, og det vil bebrejde dig, hvis du ikke erklærede en metode med kamel sag for eksempel.,
jeg finder toner af junior-udviklere, der forsøger at kæmpe mod denne, fordi de kan lide en bestemt formatering, men uden at dette værktøj, dette store software-programmer vil ligne en frankenstein monster på en fremtidig stigende vanskeligheder med at læse alle dele eller følge nogle metode stier og klasse tilsidesættes. Tænk på det som at læse en bog om, hvor hvert afsnit har en anden skriftstørrelse, font-familie og så.
hvor ikke at bruge det?
dette punkt er så nemt: Brug det ikke på dynamisk kontekst og på ikke-programmeringssprog.
1. Den første er let at forstå., Hvis du er i en dynamisk kontekst, vil lint (en statisk checker) aldrig vide det endelige resultat og vil bebrejde dig for ting, der er OK, jeg tilføjer et eksempel på det næste punkt.
2. Dette skal lyde latterligt, overflødigt, eller du kan fortælle mig “hvor du bruger en fnug, hvis det ikke er på et programmeringssprog?”Mulder, der er HTML og CSS linters derude.
Yea.. um… Men hvordan?,
Tja, de er ikke linters i sandhed, de er kun code-tern, det samme kan du gøre med w3c validator, men i stedet på at kopiere din kode i en validator, som de plejer at køre på udvikling tid at beskylde dem for forskellige ting baseret på nogens mening, hvilket er irriterende, unøjagtige, og egentlig ikke passer i dag er brugen af disse to teknologier (eller tre, hvis du tilføjer SCSS), og vigtigst, de normalt ikke har en grund til hvert udsagn, eller de grunde, der er i modstrid fra et punkt til et andet, eller årsagen er forældede, eller de grunde, er ikke relevante for alle projekter., Derfor finder du toner af “Glem CSSLint, det er opfattet og passer ikke til dit projekt” kommentarer og mange lignende andre på tværs af internettet.
Du kan finde nogle stykker kode, der kaldes Linters af en eller anden grund, men i det mindste fortæller de dig “i’ am an opinionated code formatter” som denne .,
HTML-lint, kan være nyttigt sommetider, da det vil tvinge dig til at tilføje en alt attribut til billeder og andre tilgængelighed og god praksis (de Fleste vestlige lande, viser en advarsel for det, også uden at tilføje et bånd, som er bedre) men det vil ikke forhindre dig i at bruge en <span> som <p> eller andre dårlige html-brug.
det vil også irritere dig, hvis du skriver skabelonkomponenter med fjollede udsagn som “du har ikke doctype-erklæring, du har ikke html, hoved, titel eller kropsmærke., Og du kunne ting “selvfølgelig, da denne fil vil blive indlæst i et dokument, der allerede har disse tags”, men HTML lint kan ikke vide det; Lints er statiske brikker, og du arbejder på et dynamisk miljø, så gå videre og slet html lint overhovedet.
CSSLint er lidt anderledes, der er ingen ting, du kan lint her alligevel, du kan skrive gyldig eller ugyldig CSS, men det er alt.,
Der er god praksis på CSS, der står for effektivitet og hastighed formål (det vil også gavne UX), andre, at der vil gå til vedligeholdelse, skalerbarhed og læsbarhed formål (normalt baseret på erfaringer med udvikling), en anden af dem stå for tilgængelighed (baseret på UI/UX undersøgelser og browser puds, skærmens kontrast, tests og så). Men der er ingen mening om at kombinere det hele i en linter og fortælle devs at matche alle disse praksis, først og fremmest fordi der er modsætninger, der har brug for et menneske til at træffe beslutningen om at bruge en eller anden.,
en brugssag, hvor man skal vælge, kan håndteres af det faktum, at tilføjelse af al tilgængelighed CSS-kode vil observerbart øge størrelsen, indlæsningstiden og første gang interaktive målinger, så du normalt kun vælger de tilgængelighedsregler, der passer bedst til dine kunder, mens du opretholder god ydelse.
for at sætte et dumt eksempel på en opinioneret regel om CSSLint lad os sige, at jeg vil have en lineær gradient som baggrund på min hjemmeside hovedblok. CSSLint vil kaste en advarsel om lineær gradient ydeevne.,
på dette tidspunkt vil CSSLint have dig til at slette den lineære gradient, men hvad er alternativerne?
Brug af et billede vil være toner af gange mindre effektive til at nå målet design (og også vil reducere den visuelle kvalitet af gradienten, og vil gøre det sværere at ændre størrelsen til at passe alle posible størrelser af blokken).
Så hvad kan vi gøre? Bare ignorere CSSLint, fordi det er opfattet, og dette understøttes ikke af nogen grund.
der er forskel på at tilføje en lineær gradient vs tilføje 42342 lineære gradienter på samme visning., Forresten, hvis du har brug for dem, vil det stadig være mere effektivt end at bruge billeder.
Du kan også finde modstridende udsagn om det sådan:
“brug ikke id ‘ er til styling”. Årsagen er, at det vil være en ikke-genanvendelig regel.
og
“Brug ikke tilstødende klasser”. Jeg kunne ikke rigtigt finde ud af grunden uden at læse css lint regler forklaring, og årsagen er, “Mens teknisk tilladt i CSS, disse er ikke håndteres korrekt i Internet Explorer 6 og tidligere”.
Jeg har noget at fortælle dig CSSLint., Ingen bekymrer sig om IE 6 og tidligere, er vi i 2020, 99% af web-software understøtter I. E. 11 så meget, som blev udgivet på 2013 med den måde, og har mindre end 3% forbrug.
På den anden side, hvor for Guds skyld er det udtrykt, at alle CSS-regler skal genbruges på samme visning?
Hvis du har et unikt emne på din appebapp, dvs. du har sandsynligvis kun en navbar, kun en chat-popup, hvis nogen, kun et navbar-logo og kun en sidefod til at navngive nogle, hvorfor skal du tilføje det styling global? Er det ikke sådan en dårlig praksis, der er i strid med alle andre sprog rundt om i verden?,
som en tilføjelse, lad os sige, at du har 5 visninger på dit projekt. Hvis du har en <nav> det vil sandsynligvis blive vist på dem alle, så den samme styling du lægger under #primary-navigation arbejder på 5 forskellige visninger. Er det ikke en måde at genbruge?
for at øge silliness omkring, at begge regler sammen, se hvordan det lader dig på en vanskelig situation.,
Hvis du ikke kan bruge et id for styling <nav class="dark-theme">, og du kan ikke tilføje tilstødende klasser<nav class="primary-navigation dark-theme">, hvordan du vil håndtere til omfanget din styling og gøre det mere at vedligeholde, læsbar og hvordan vil du gøre det for at tilføje java-script hændelses-lyttere, når der er behov for på en effektiv måde?
Du kan simpelthen ikke.
hvad vi kunne gøre semantisk korrekt og let at vedligeholde?, Lad os sætte et eksempel:
Her er endnu en erklæring om, at få mig til at grine i et stykke tid:
Undgå ubetinget attribut selectors “Ukvalificeret attribut-selektorer, som matcher alle elementer, først og derefter tjekke deres attributter. Dette betyder, at ukvalificerede attributvælgere har de samme ydeevneegenskaber som universal selector (*)”
min elskede, dette er ikke anderledes end hvad der sker, når du bruger klasse, id eller tag selector.
stadierne i Bro .ser CSS-gengivelse er:
- opbygning af DOM., DOM er en trælignende datastruktur, der indeholder alle HTML-noder på siden. Hver node indeholder dataene om det HTML-element (såsom attributter, id ‘ er og klasser) hvis noden har HTML-elementer som børn, vil det også pege på disse børneknuder.
- opbygning af CSSOM. Når bro .seren støder på et CSS-stilark (enten indlejret eller eksternt), skal den analysere teksten til noget, den kan bruge til stillayout og maling. Den datastruktur, som bro .seren forvandler CSS til, kaldes kreativt CSSOM.
- generering af et Gengivelsestræ., Kort sagt, gengivelsestræet indeholder alle de oplysninger, der er nødvendige for, at bro .seren kan oprette pi .els på siden. Browseren dybest set tager DOM og CSSOM og squash dem sammen, for at fjerne noget, der ikke vil have en effekt på den genererede output.
- Layout og maleri.
i Layoutfasen finder bro .seren størrelsen og placeringen af elementerne (intet gengivet endnu), og derefter begynder det på malingstrinnet at generere pi .els, som vi vil visualisere.,
Som du kan se kan du få en lille performance bias, når indlejring i flæng din selektorer, som f.eks. body>#main-content>.first-block .products-card p som du vil generere unødvendige barn noder i CSSOM, der bliver nødt til at matche den DOM, og dette vil tage lidt mere tid end ved brug af blot en.products-card p, men som vi bliver nødt til at opretholde denne kode og sandsynligvis skalere det, vi skal anvendelsesområde reglerne, så lad os sige, at #main-content .products-card p.
det er en god praksis, men jeg har aldrig set en appebapp, hvor mere specifikke vælgere forårsager flaskehals i belastningshastigheden., Denne regel er forårsaget af iteration over og over igen at holde toner af ubrugte kode, som browseren vil tilføje, i CSSOM og bliver nødt til at sammenligne med DOM til at finde ud af, om det er OK at tilføje det i render-træet eller ej.
af denne og andre mange grunde er, hvorfor du kan finde artikler, der forklarer hvert forkert punkt på CSSLint som denne, der forklarer tingene på en mere omfattende måde end jeg gjorde her.
resum.
Linters er gode til nogle ting og dårlige for andre.,
de kan også redigeres for at passe til nogle projektbehov eller nogle virksomheds-eller personpræferencer for at undgå disse regler, der er meningsfulde og tilføje andre værdifulde regler, der passer til det projekt, du er i.
Der er mange grunde til at bruge linters på fortolket sprog (på samlet dem, IDE og compileren vil tage sig af dette, men du kan også tilføje et Fnug til at kontrollere kode formatering eller for at få advarsler, før kompilere at undgå at vente, indtil compiler finder en fejl eller ender til at vide, om det hele er OK).,
Der er få grunde til at tilføje linters til HTML (kun tilgængelighedsformål kan være nyttige, tror jeg), og der er færre grunde til at tilføje linters på CSS (det kan reduceres til en kode en formateringskontrol).
har du brugt en fnug? Hvis ja, fortæl os på hvilket sprog og kontekst, og hvad var din oplevelse.
jeg personligt kunne lide det efter få T .eaks, når du bruger TypeScript.
som altid, håber du kan lide dette indlæg og venlig hilsen,
Joel