för en tid sedan hjälper jag en junior utvecklare, som har ett uppenbart problem på honom kod, för att ta reda på vad som var fel på det. Han installerade en ludd och hämtade (Gud vet varför) en anpassad ordbok för den. Jag förberedde en liten testmiljö och visade honom skillnaden mellan olika tester, på olika punkter och vissa begränsningar av varje (på denna lilla miljö).
nyligen pratade jag om att testa med en kollega och jag kom ihåg denna anekdot och berättade för mig själv att skriva ett inlägg om det eftersom det kunde vara intressant för många.,
vad är linting?
Linting är den automatiska kontrollen av din källkod för programmatiska och stilistiska fel. Detta görs genom att använda ett lintverktyg (Alias linter). En ludd verktyg är en grundläggande statisk kod analysator.
termen linting kommer ursprungligen från ett Unix-verktyg för C. Det finns många kodlinters tillgängliga för olika programmeringsspråk idag.
Lint programmering är en typ av automatisk kontroll. Det kan hända tidigt i utvecklingen, före kodrecensioner och testning. Det beror på att automatiserade kodkontroller gör kodöversynen och testprocesserna effektivare., Och de frigör dina utvecklare att fokusera på rätt saker.
många automatiserade testverktyg utnyttjar en inbyggd linter för att kasta fel, ställa in några poäng om kodkvalitet och blockera sammanställningen eller en driftsättningsstadium om denna poäng är lägre än önskat (automatiskt eller pausa processen kasta ett meddelande för att manuellt kontrollera om detta ”fel” ska lappas eller inte).
vad är avsett för?
Linting syftar till att minska fel och förbättra den övergripande kvaliteten på devs-koden, påskynda utvecklingen och minska kostnaderna genom att hitta fel tidigare.,
När ska du använda Lint-programvara?
om det här är nytt för dig kan du vara lite hyped med lints vid denna tidpunkt men de är inte ett programagiskt verktyg. En lint är helt enkelt en ”scrapper” / filläsare skript med en fil (vanligtvis en json eller xml) med fördefinierade (eller anpassade) regler om hur koden måste se ut. IDEs har faktiskt en inbyggd Lint som kommer att kasta dig ett fel (dvs om du ringer en obefintlig metod, eller om du försöker lägga till ett strängvärde i ett heltal variabel) eller en varning (dvs., om du deklarerar en variabel inuti en villkorlig och sedan returnerar du den variabeln i slutet av din metod). Men jag pratar inte om den inbyggda kodlinten, eftersom dessa linters är ”mjuka” och tillåtande, annars kommer många inte att använda dessa IDEs, vi kommer att se varför senare.
Du kan använda en specifik ludd om du passar in i dessa uttalanden:
När du använder tolkade programmeringsspråk.
vissa språk är bättre lämpade för kod linting än andra. PHP, Python och JavaScript tolkas språk, det betyder att de saknar en kompileringsfas*., Så att använda lint programvara är effektiv för att säkerställa konsekvent kodning stil och lösa grundläggande kodning fel i dessa fall.
men när det gäller kompilerade språk, till exempel C och C++, kanske det inte räcker med att använda lint-programvara. C och C++ är komplexa och kan kräva mer avancerad kodanalys.
*Du kan skrika Jag kompilera JavaScript! men det är faktiskt inte sant. Numera på framsidan använder vi verktyg som bundlers, lägga till några javascript-verktyg som passerar våra js av vissa faser som minify, ugglify, ofuscate. Några av dessa verktyg tar också bort oanvänd kod på dess utgång., Men inget av det här betyder att du sammanställer javascript, eftersom utmatningen blir en .JS fil ändå; ingen bytecode, ingen assembler.
det är sant att du kan konvertera javascript till webbmontering men det är inte en direkt väg från en till en annan; du måste konvertera din js till något ”kompilerbart” sådan C-kod och sedan sammanställa den till webbmontering.
När du använder standardregler
Detta är lite knepigt uttalande., På ett programmeringsspråk kommer du inte att kunna använda något som inte är inbyggt på ditt programmeringsspråk (det är inte sant alls, eftersom du kan lägga till bibliotek eller kasta systemkommandon från programmeringsspråk, men ändå har Lint inget att göra med det…)
vilka standardregler står för?
med hjälp av en ram passar bra här, måste du använda RAM inbyggda metoder för att nå önskad utgång.
ibland standardregler innebär fashionably kod., Dessa metoder och lösningar som samhället upprepar som ett mantra tills de hittar ett annat fashionabelt sätt att nå målet för en given uppgift, eller tills någon med offentlig repercussion berättar för samhället ”Hej, jag analyserade dessa lösningar och jag tycker att det finns ett bättre sätt att nå detta av denna anledning” och sedan går samhället vidare.
När dina behov är grundläggande
Lint verktyg är bra för grundläggande analys. Men om du behöver mer sofistikerad analys måste du leta någon annanstans (automatiserade testverktyg och testdriven utveckling).
Var ska jag se en ludd?
1., På automatiserade tester (vi kallar dem automatiserade eftersom de körs automatiskt men någon behöver koda testet för varje användningsfall på en app) som Cypress, kan du lägga till en ludd för att göra mål kodkvaliteten.
detta kan köras på utvecklingstid (när dev träffar testknappen) eller sannolikt på deploy-scenen. Till exempel, när du trycker på något i master branch kan det vara en utlösare för att höja testen, inklusive ludd, och blockera distributionen (och skylla dig) om du gjorde något fel, måste du reparera eller hitta felet (det betyder inte att det är ditt fel., Jag kan driva ett API som gör att din klient kraschar emot oväntade värden, och det här blir mitt fel, inte ditt).
dessa tester är inte avsedda att skylla på dig, men för att hjälpa till i utvecklingsprocessen är det vanligtvis bättre att hitta en bugg innan den integreras i förproduktionsstadiet på grund av ett testfel än att hitta det överraskande i produktionen.
2. På stora projekt, vanligtvis på stora företag., Om du är på ett mycket stort företag projektledaren skulle vilja alla koden ser ut som samma (formatering) så de har förmodligen en ludd för det någonstans som pekar dig om du lagt 4 vita utrymmen att indrag något de vill med 2 och som kommer att skylla dig om du inte deklarerar en metod med kamel fall till exempel.,
Jag tycker att toner av junior devs försöker kämpa mot det eftersom de gillar en viss formatering, men utan de här verktygen kommer de här stora programvaruapparna att se ut som ett frankenstein-monster på en framtid som ökar svårigheten att läsa alla delar eller följa några metodvägar och klassöverstyrningar. Tänk på det som att läsa en bok om var varje stycke har en annan teckenstorlek, typsnitt-familj och så.
var man inte ska använda den?
denna punkt är så lätt: använd den inte på dynamiska sammanhang och på icke-programmeringsspråk.
1. Den första är lätt att förstå., Om du är i ett dynamiskt sammanhang kommer linten (en statisk checker) aldrig att känna till slutresultatet och kommer att skylla dig för saker som är OK, jag lägger till ett exempel på Nästa punkt.
2. Detta borde låta löjligt, överflödigt eller du kan berätta för mig ” var du använder en ludd om det inte finns på ett programmeringsspråk?”
Mulder, det finns HTML och CSS-linters där ute.
Ja.. um… Men hur?,
de är Väl inte linters i sanning, de är bara kod-brickor, samma kan du göra med w3c validator, men istället för att kopiera din kod i en validator, de brukar köra på utveckling gången skyller på dig för olika saker baserat på någons yttrande, vilket är irriterande, felaktiga och verkligen inte passar numera användning av denna teknik (eller tre om du lägger till SCSS), och viktigaste, de brukar inte ha en anledning för varje uttalande, eller de skäl som motsäger från en punkt till en annan, eller skälet är föråldrade, eller skälen är inte tillämpliga i alla projekt., Det är därför du hittar toner av ”Glöm CSSLint, det är påstridigt och passar inte ditt projekt” kommentarer och många liknande andra över internet.
Du kan hitta några bitar av kod som kallas Linters av någon anledning, men åtminstone de berätta ” I ’am en påstridig kod formatter” som den här .,
HTML-ludd kan vara användbart ibland eftersom det kommer att tvinga dig att lägga till ett alt-attribut till bilderna och annan tillgänglighet och god praxis (de flesta IDEs visar en varning för det också utan att lägga till en ludd, vilket är bättre) men det hindrar dig inte från att använda en<span> som en<p> eller annan dålig HTML-användning.
det kommer också att irritera dig om du skriver mallkomponenter med dumma uttalanden som ”du har inte doctype-deklaration, du har inte html, huvud, titel eller kroppstagg., Och du kan sak ”naturligtvis, eftersom den här filen kommer att laddas inuti ett dokument som redan har dessa taggar” men HTML ludd kan inte veta det; Lints är statiska pjäser och du arbetar på en dynamisk miljö, så gå vidare och ta bort html ludd alls.
CSSLint är lite annorlunda, det finns ingen sak du kan luta här ändå, Du kan skriva giltig eller ogiltig CSS men det är allt.,
det finns goda metoder för CSS som står för effektivitet och hastighet (det kommer också att gynna UX), andra som kommer att gå för underhåll, skalbarhet och läsbarhet (vanligtvis baserat på utvecklingserfarenhet), en annan står för tillgänglighet (baserat på UI/UX-studier och webbläsarrenderingar, skärmkontrasttester och så). Men det finns ingen mening med att kombinera allt till en linter och berätta för devs att matcha alla dessa metoder, först och främst för att det finns motsägelser som behöver en människa för att fatta beslutet att använda en eller annan.,
ett användningsfall där du ska välja kan hanteras av det faktum att lägga till alla tillgänglighet CSS-kod kommer observerbart öka storlek, laddningstid, och första gången interaktiva mätvärden så att du vanligtvis kommer att välja endast tillgänglighetsregler som passar bäst för dina kunder samtidigt som goda resultat.
för att ställa in ett dumt exempel om en påstridig regel på CSSLint låt oss säga att jag vill ha en linjär gradient som bakgrund på min hemsida huvudblock. CSSLint kommer att kasta en varning om linjär gradient prestanda.,
vid denna punkt CSSLint vill du ta bort linjär-gradient men vad är alternativen?
att använda en bild kommer att vara toner av gånger mindre effektiva för att nå måldesignen (och kommer också att minska gradientens visuella kvalitet och göra det svårare att ändra storlek för att passa alla möjliga storlekar på blocket).
så vad kan vi göra? Helt enkelt ignorera CSSLint, eftersom det är påstridigt och detta stöds inte av någon anledning.
det finns en skillnad på att lägga till en linjär gradient vs lägga 42342 linjära gradienter på samma vy., Förresten om du behöver dem, kommer det fortfarande att vara effektivare än att använda bilder.
Du kan också hitta motsägelsefulla uttalanden om det:
”använd inte ID för styling”. Anledningen är att det kommer att bli en icke återanvändbar regel.
och
”Använd inte angränsande klasser”. Jag kunde inte riktigt räkna ut orsaken utan att läsa CSS ludd regler förklaring och anledningen är ”medan tekniskt tillåtet i CSS, dessa hanteras inte korrekt av Internet Explorer 6 och tidigare”.
Jag har något att berätta för dig csslint., Ingen bryr sig om IE 6 och tidigare, vi är 2020, 99% av webbprogramvaran stöder I. E. 11 lika mycket, som släpptes 2013 förresten och har mindre än en 3% Användning.
å andra sidan, var för Guds skull det uttrycks att alla CSS-regler måste återanvändas på samma vy?
om du har ett unikt objekt på din webbapp, dvs du har sannolikt bara en navbar, bara en chatt popup om någon, bara en navbar logotyp och bara en sidfot för att namnge några, varför behöver du lägga till det styling global ? Är det inte en sådan dålig praxis som strider mot alla andra språk runt om i världen?,
som ett tillägg, låt oss säga att du har 5 visningar på ditt projekt. Om du har en <nav> kommer det sannolikt att visas på dem alla, så samma styling som du lägger under #primary-navigation arbetar med 5 olika vyer. Är inte detta ett sätt att återanvända?
för att öka silliness runt att båda reglerna tillsammans, se hur det låter dig på en svår situation.,
om du inte kan använda ett ID för styling <nav class="dark-theme">, och du inte kan lägga till intilliggande klasser<nav class="primary-navigation dark-theme">, hur kommer du att kunna utöka din styling och göra den mer underhållbar, läsbar och hur hanterar du den för att lägga till java-script händelselyssnare när det behövs på ett effektivt sätt?
Du kan helt enkelt inte.
vad vi kan göra semantiskt korrekt och lätt att underhålla?, Låt oss ange ett exempel:
Här är ett annat uttalande som får mig att skratta ett tag:
Undvik okvalificerade attributväljare ” okvalificerade attributväljare, till exempel matcha alla element först och kontrollera sedan deras attribut. Det betyder att icke-kvalificerade attributväljare har samma prestandaegenskaper som universalväljaren (*)”
min älskling, det här skiljer sig inte från vad som händer när du använder klass, id eller taggväljare.
stegen i webbläsaren CSS rendering är:
- bygga DOM., DOM är en trädliknande datastruktur som innehåller alla HTML-noder på sidan. Varje nod innehåller data om det HTML-elementet (t.ex. attribut, ID och klasser) om noden har några HTML-element som barn, kommer det också att peka på de underordnade noderna.
- bygga CSSOM. När webbläsaren stöter på en CSS-stilmall (antingen inbäddad eller extern) måste den tolka texten till något den kan använda för stillayouter och färger. Den datastruktur som webbläsaren förvandlar CSS till kreativt heter cssom.
- generera ett Renderträd., Kort sagt, render tree innehåller all information som behövs för webbläsaren för att skapa pixlar på sidan. Webbläsaren tar i princip DOM och CSSOM och squashes dem tillsammans, ta bort allt som inte kommer att ha en effekt på den renderade produktionen.
- Layout och målning.
i Layoutfasen räknar webbläsaren ut elementets storlek och position (inget återges ännu) och sedan börjar det på färgsteget generera pixlar som vi visualiserar.,
Som du kan se kan du få en liten performance bias när häckande urskillningslöst dina väljare, till exempel body>#main-content>.first-block .products-card p som du kommer att generera onödiga noder barn i CSSOM som kommer att behöva för att matcha DOM och detta kommer att ta lite mer tid än att använda bara en.products-card p, men som vi behöver för att behålla denna kod och förmodligen skala den, vi måste tillämpningsområde reglerna så låt oss säga #main-content .products-card p.
det är en bra praxis, men jag har aldrig sett en webbapp där mer specifika väljare orsakar flaskhalsen lasthastighet., Detta orsakas oftast av iteration om och om igen hålla toner av oanvänd kod som webbläsaren kommer att lägga till i CSSOM och kommer att behöva jämföra med DOM att räkna ut om det är OK att lägga till den i render tree eller inte.
för detta och andra många anledningar är varför du kan hitta artiklar som förklarar varje fel punkt på CSSLint som den här som förklarar saker på ett mer omfattande sätt än jag gjorde här.
sammanfattning
Linters är bra för vissa saker och dåliga för andra.,
de kan också redigeras för att passa vissa projektbehov eller vissa företag eller personpreferenser för att undvika dessa regler som är påstridiga och lägga till andra värdefulla regler som passar det projekt du befinner dig i.
det finns många anledningar till att använda linters på tolkade språk (på kompilerade sådana, IDE och kompilatorn kommer att ta hand om detta, men du kan också lägga till en Lint för att kontrollera kodformatering bara eller för att få varningar innan kompilera för att undvika att vänta tills kompilatorn hittar ett fel eller slutar att veta om det är allt OK).,
det finns få skäl att lägga till linters i HTML (endast tillgänglighetsändamål kan vara användbara tror jag) och det finns färre skäl för att lägga till linters på CSS (som kan reduceras till en kod en formateringskontroll).
har du använt en ludd? Om så är fallet, berätta i vilket språk och sammanhang och vad var din erfarenhet.
Jag gillade det personligen efter några tweaks när du använder TypeScript.
som alltid, hoppas du gillar det här inlägget och hälsningar,
Joel