enige tijd geleden assisteer ik een junior ontwikkelaar, die een duidelijk probleem heeft met zijn code, om erachter te komen wat er mis was. Hij installeerde een pluis en downloadde er (god weet waarom) een aangepast woordenboek voor. Ik bereidde een kleine testomgeving en toonde hem het verschil tussen verschillende tests, op verschillende punten en een aantal beperkingen van elk (op deze kleine omgeving).
onlangs sprak ik over testen met een collega en ik herinnerde me deze anekdote en vertelde mezelf om een post over te schrijven omdat het interessant kan zijn voor velen.,
Wat is linten?
Linting is de automatische controle van uw broncode op programmatische en stilistische fouten. Dit wordt gedaan met behulp van een pluis tool (a.k.a. linter). Een pluis tool is een basis statische code analyzer.
De term linting komt oorspronkelijk van een UNIX utility voor C. Er zijn tegenwoordig veel codelinters beschikbaar voor verschillende programmeertalen.
Lint programmeren is een soort automatische controle. Het kan vroeg in de ontwikkeling gebeuren, voordat code reviews en testen. Dat komt omdat geautomatiseerde codecontroles de codebeoordeling en testprocessen efficiënter maken., En ze laten je ontwikkelaars zich richten op de juiste dingen.
veel geautomatiseerde testtools maken gebruik van een ingebouwde linter om fouten te gooien, een score in te stellen over de kwaliteit van de code en het compileren of een implementatiefase te blokkeren als deze score lager is dan de gewenste (automatisch of pauzerend het proces waarbij een melding wordt gegeven om handmatig te controleren of deze “fouten” moeten worden gepatcht of niet).
waarvoor is het bestemd?
Linting is bedoeld om fouten te verminderen en de algehele kwaliteit van devs-code te verbeteren, de ontwikkeling te versnellen en de kosten te verlagen door fouten eerder te vinden.,
wanneer pluis software gebruiken?
als dit nieuw voor je is, kan het zijn dat je op dit moment een soort hyped bent met lints, maar ze zijn geen programmagisch hulpmiddel. Een lint is gewoon een”scrapper” /file reader script met een bestand (meestal een json of xml) met vooraf gedefinieerde (of aangepaste) regels over hoe de code eruit moet zien. In feite hebben IDEs een ingebouwde pluis die je een fout zal gooien (dwz als je een niet-bestaande methode aanroept, of als je probeert een string waarde toe te voegen aan een integer variabele) of een waarschuwing (dwz., als je een variabele declareert binnen een voorwaardelijke en dan geef je die variabele terug aan het einde van je methode). Maar ik heb het niet over de ingebouwde codepluis, omdat deze linters “zacht” en tolerant zijn, anders zullen veel mensen die IDEs niet gebruiken, we zullen later zien waarom.
u kunt een specifiek Lint gebruiken als u in deze statements past:
wanneer u geïnterpreteerde programmeertalen gebruikt.
sommige talen zijn beter geschikt voor het linten van code dan andere. PHP, Python en JavaScript zijn geà nterpreteerde talen, dit betekent dat ze een compilatiefase*missen., Dus met behulp van lint software is effectief voor het waarborgen van consistente codering stijl en het oplossen van fundamentele codering fouten in deze gevallen.
maar als het gaat om gecompileerde talen, zoals C en c++, kan het gebruik van lint software niet genoeg zijn. C en c++ zijn complex en vereisen mogelijk meer geavanceerde code-analyse.
*u kunt schreeuwen Ik compileer JavaScript! maar het is in feite niet waar. Tegenwoordig op front-end zijn we met behulp van tools zoals bundlers, het toevoegen van een aantal javascript tools die onze js passeren door een aantal fasen, zoals minify, ugglify, ofuscate. Sommige van deze tools verwijderen ook ongebruikte code op de uitvoer., Maar niets van deze dingen betekent dat u javascript compileren, als de output zal een .js bestand toch; geen bytecode, geen assembler.
Het is waar dat je javascript kunt converteren naar web assembly, maar het is geen direct pad van de ene naar de andere; Je moet je js converteren naar iets “compilable” zoals C-code en het dan compileren naar web assembly.
wanneer u standaardregels
gebruikt, is dit een lastig statement., Op een programmeertaal zul je niet in staat zijn om iets te gebruiken dat niet is ingebouwd in je programmeertaal (dat is helemaal niet waar, omdat je bibliotheken kunt toevoegen of systeem commando ‘ s uit programmeertalen kunt gooien, maar hoe dan ook pluis hebben daar niets mee te maken dus…)
Waar staan standaardregels voor?
het gebruik van een framework past hier goed, je moet ingebouwde framework methoden gebruiken om de gewenste output te bereiken.
soms betekent standaardregels modieus code., Deze methodologieën en oplossingen die de gemeenschap herhalen als een mantra totdat ze een andere modieuze manier vinden om het doel van een bepaalde taak te bereiken, of totdat iemand met publieke Repercussie de gemeenschap vertelt “hey, Ik was het analyseren van deze oplossingen en ik vind dat er een betere manier om dit te bereiken om deze redenen” en dan gaat de Gemeenschap verder.
wanneer uw behoeften basis zijn
Pluisgereedschappen zijn geweldig voor basisanalyse. Maar als je meer geavanceerde analyse nodig hebt, moet je elders kijken (geautomatiseerde testtools en testgestuurde ontwikkeling).
waar moet ik een pluis zien?
1., Op geautomatiseerde tests (we noemen ze geautomatiseerd omdat ze automatisch worden uitgevoerd, maar iemand moet de test te coderen voor elke use case op een app) zoals Cypress, kunt u een lint toe te voegen aan de kwaliteit van de code te scoren.
Dit kan draaien op ontwikkeltijd (wanneer de dev op de testknop drukt) of waarschijnlijk op de implementatiefase. Bijvoorbeeld, als je iets pusht naar master branch kan het een trigger zijn om de tests te verhogen, inclusief het lint, en de implementatie te blokkeren (en je de schuld te geven) als je iets verkeerd hebt gedaan, dan moet je de bug repareren of vinden (dit betekent niet dat het jouw fout is., Ik zou een API kunnen pushen die ervoor zorgt dat je cliënt crasht en onverwachte waarden ontvangt, en dit zal mijn schuld zijn, niet de jouwe).
deze tests zijn niet bedoeld om u de schuld te geven, maar om te helpen in het ontwikkelingsproces, is het meestal beter om een bug te vinden voordat ze worden geïntegreerd in de pre-productiefase vanwege een testfout dan het bij verrassing te vinden in de productie.
2. Op grote projecten, meestal op grote bedrijven., Als je op een zeer groot bedrijf de project manager zou willen dat alle code er hetzelfde uitzien (opmaak) dus ze hebben waarschijnlijk een pluis voor het ergens dat je wijst als je 4 witte spaties toegevoegd om iets wat ze willen inspringen met 2 en dat zal je de schuld als je niet declareren Een methode met camel case bijvoorbeeld.,
Ik vind tonen van junior devs proberen om te vechten tegen dat omdat ze graag een bepaalde opmaak, maar zonder deze tools, deze grote software apps zal eruit zien als een frankenstein monster op een toekomst het verhogen van de moeilijkheid op het lezen van alle delen of het volgen van een methode paden en klasse overrides. Denk erover als het lezen van een boek over waar elke paragraaf hebben een andere lettertype-grootte, lettertype-familie en zo.
waar niet gebruiken?
Dit punt is zo eenvoudig: gebruik het niet op dynamische context en niet-programmeertalen.
1. De eerste is gemakkelijk te begrijpen., Als je in een dynamische context de lint (een statische checker) zal nooit weten het eindresultaat en zal u de schuld voor dingen die OK zijn, Ik zal een voorbeeld toe te voegen op het volgende punt.
2. Dit zou belachelijk moeten klinken, overbodig of je kunt me vertellen ” waar je een pluis gebruikt als het niet in een programmeertaal is?”
Mulder, er zijn HTML-en CSS-linters.
Ja.. um… Maar, hoe?,
nou, het zijn geen linters in waarheid, het zijn alleen code-checkers, hetzelfde wat je kunt doen met de W3C validator, maar in plaats daarvan, bij het kopiëren van je code in een validator, draaien ze meestal op ontwikkelingstijd en geven je de schuld voor verschillende dingen op basis van iemands mening, wat vervelend is, onnauwkeurig en echt niet past tegenwoordig gebruik van deze twee technologieën (of drie als je SCSS toevoegt), en het belangrijkste, ze hebben meestal geen reden voor elke verklaring, of de redenen spreken van een punt naar een ander, of de reden is verouderd, of de redenen zijn niet van toepassing op alle projecten., Daarom vindt u tonen van “Vergeet csslint, het is eigenwijs en past niet bij uw project” opmerkingen en vele soortgelijke anderen op het internet.
u kunt een aantal stukjes code vinden die Linters worden genoemd om een of andere reden, maar ze vertellen u tenminste “ik ben een eigenzinnige code formatter” zoals deze .,
HTML-lint kan soms handig zijn als het zal je dwingen om een alt attribuut om de beelden en andere toegankelijkheid en goede praktijken (de Meeste Ide ‘ s ziet u een waarschuwing voor het ook zonder toevoeging van een lint, dat is beter) maar dit zal niet voorkomen dat u van het gebruik van een <span> een <p> of andere slechte html gebruik.
het zal je ook irriteren als je sjablooncomponenten schrijft met domme statements zoals “you don’ t have doctype declaration, you don ‘ t have html, head, title or body tag., En je zou kunnen ding “natuurlijk, als dit bestand zal worden geladen in een document dat al deze tags” maar HTML lint kan het niet weten; Lints zijn statische checkers en je werkt aan een dynamische omgeving, dus ga verder en verwijder html lint helemaal.
CSSLint is een beetje anders, Er is niets dat je hier toch kunt pluizen, je kunt geldige of ongeldige CSS schrijven, maar dat is alles.,
Er zijn goede praktijken op het gebied van CSS die staan voor efficiëntie en snelheid doeleinden (het zal ook ten goede komen aan UX), andere die gaan voor onderhoudbaarheid, schaalbaarheid en leesbaarheid doeleinden (meestal gebaseerd op ervaring met ontwikkeling), andere die staan voor toegankelijkheid (gebaseerd op UI/UX studies en browser renderings, scherm contrast tests en zo). Maar het heeft geen zin om het allemaal te combineren tot een linter en devs te vertellen om al die praktijken te matchen, ten eerste omdat er tegenstrijdigheden zijn die een mens nodig hebben om de beslissing te nemen om de een of andere te gebruiken.,
Een use case waar te kiezen zou kunnen worden behandeld door het feit dat het toevoegen van alle toegankelijkheid CSS-code zal merkbaar toenemen de grootte, laadtijd, en de eerste keer interactieve statistieken, zodat u meestal kiest alleen de toegankelijkheidsregels die het beste past bij uw klanten met behoud van goede prestaties.
Voor het instellen van een dom voorbeeld over een opinionated regel op de CSSLint laten we zeggen dat Ik wil een lineair-gradiënt als achtergrond op mijn homepage hoofdblok. CSSLint zal een waarschuwing geven over lineair-gradiënt prestaties.,
Op dit punt wil CSSLint dat je het lineaire verloop verwijdert, maar wat zijn de alternatieven?
het gebruik van een afbeelding zal tonen van tijden minder efficiënt zijn om het doelontwerp te bereiken (en zal ook de visuele kwaliteit van de gradiënt verminderen, en zal het moeilijker maken om de grootte van alle mogelijke groottes van het blok aan te passen). dus wat kunnen we doen? Gewoon negeren de CSSLint, want het is eigenwijs en dit wordt niet ondersteund door enige reden.
er is een verschil bij het toevoegen van een lineair-gradiënt versus het toevoegen van 42342 lineaire-gradiënten in dezelfde weergave., By the way als je ze nodig hebt, het zal nog steeds efficiënter dan het gebruik van afbeeldingen.
u kunt er ook tegenstrijdige uitspraken over vinden zoals:
“Gebruik geen ID ‘ s voor styling”. De reden is dat het een niet herbruikbare regel zal zijn.
en
“Gebruik geen aangrenzende klassen”. Ik kon niet goed achterhalen van de reden zonder het lezen van de CSS lint regels uitleg en de reden is “hoewel technisch toegestaan in CSS, deze worden niet goed behandeld door Internet Explorer 6 en eerder”.
Ik heb je iets te vertellen CSSLint., Niemand geeft om IE 6 en eerder, we zijn in 2020, 99% van de web-software ondersteunt IE 11 zo veel, die werd uitgebracht op 2013 door de manier en heeft minder dan een 3% gebruik.
anderzijds, waar in godsnaam wordt gezegd dat alle CSS-regels opnieuw bruikbaar moeten zijn op dezelfde manier?
Als u een uniek item op uw web-app hebt, dat wil zeggen dat u waarschijnlijk slechts één navbar hebt, slechts één chat popup indien aanwezig, slechts één navbar-logo en slechts één voettekst voor het benoemen van een aantal, Waarom moet u dan de styling global toevoegen? Is het niet zo ‘ n slechte praktijk die in strijd is met alle andere talen in de wereld?,
als toevoeging, laten we zeggen dat je 5 views hebt op je project. Als u een <nav> hebt, zal deze waarschijnlijk op alle afbeeldingen worden getoond, dus dezelfde styling die u hieronder plaatst #primary-navigation werkt aan 5 verschillende weergaven. Is dit niet een manier van herbruikbaarheid?
om de silliness rond die beide regels samen te vergroten, Zie hoe het je in een moeilijke situatie laat.,
Als u geen id kunt gebruiken voor styling <nav class="dark-theme">, en u kunt geen aangrenzende klassen toevoegen<nav class="primary-navigation dark-theme">, hoe kunt u dan uw styling benaderen en het onderhoudbaarder en leesbaar maken en hoe beheert u het om java-script event listeners toe te voegen wanneer dat nodig is op een efficiënte manier?
U kunt het gewoon niet.
wat kunnen we semantisch corrigeren en onderhouden?, Laten we een voorbeeld geven:
Hier is nog een statement dat me een tijdje aan het lachen maakt:
vermijd ongekwalificeerde attribuutselectors “ongekwalificeerde attribuutselectors, zoals , Komen Eerst overeen met alle elementen en controleren vervolgens hun attributen. Dit betekent dat niet-gekwalificeerde attribuutkiezers dezelfde prestatiekenmerken hebben als de universele selector (*) “
My darling, dit is niet anders dan wat er gebeurt bij het gebruik van klasse, of id, of tag selector.
de stappen van browser CSS rendering zijn:
- het bouwen van de DOM., De DOM is een boom-achtige datastructuur die alle HTML-knooppunten op de pagina bevat. Elk knooppunt bevat de gegevens over dat HTML-element (zoals attributen, ID ‘ s en klassen) als het knooppunt HTML-elementen als kinderen heeft, zal het ook naar die onderliggende knooppunten wijzen.
- bouwen van de CSSOM. Wanneer de browser een CSS-stylesheet tegenkomt (ingesloten of extern), moet het de tekst ontleden in iets dat het kan gebruiken voor stijl lay-outs en verven. De datastructuur waarin de browser CSS verandert wordt creatief de CSSOM genoemd.
- genereren van een Renderboom., Kortom, de render boom bevat alle informatie die nodig is voor de browser om pixels op de pagina te maken. De browser neemt in principe de DOM en CSSOM en plet ze samen, het verwijderen van alles dat geen effect op de gerenderde uitvoer zal hebben.
- lay-out en schilderen.
in de lay-outfase zoekt de browser de grootte en de positie van de elementen uit (nog niets weergegeven) en dan, op de paint step begint het pixels te genereren die we zullen visualiseren.,
zoals u kunt zien kunt u een kleine prestatievooroordeel krijgen wanneer u zonder onderscheid uw selectors nestelt, zoals body>#main-content>.first-block .products-card p omdat u onnodige kindknooppunten in de CSSOM zult genereren die moeten overeenkomen met de DOM en dit iets meer tijd zal kosten dan het gebruik van gewoon een.products-card p, maar omdat we deze code moeten behouden en waarschijnlijk moeten schalen, moeten we de regels aanpassen dus laten we zeggen #main-content .products-card p.
Het is een goede praktijk, maar ik heb nog nooit een web app gezien waarin meer specifieke selectors lastsnelheid bottleneck veroorzaken., Dit wordt meestal veroorzaakt door het herhalen van tonen van ongebruikte code die browser zal toevoegen aan CSSOM en zal moeten vergelijken met DOM om erachter te komen of het OK is om het toe te voegen aan de render boom of niet.
voor deze en andere vele redenen is waarom je artikelen kunt vinden die elk verkeerd punt op CSSLint uitleggen, zoals deze die dingen op een uitgebreidere manier uitleggen dan ik hier deed.
samenvatting
Linters zijn goed voor sommige dingen en slecht voor anderen.,
ze kunnen ook worden bewerkt om te voldoen aan sommige projectbehoeften of een bedrijf of persoon voorkeuren voor het vermijden van deze regels die eigenwijs zijn en het toevoegen van andere waardevolle regels die passen bij het project waarin u zich bevindt.
Er zijn veel redenen om linters te gebruiken op geinterpreteerde talen (op gecompileerde talen zorgen de IDE en de compiler hiervoor, maar je kunt ook een pluis toevoegen om alleen de code opmaak te controleren of om waarschuwingen te krijgen voor het compileren om te voorkomen dat de compiler een fout vindt of eindigt om te weten of alles in orde is).,
Er zijn weinig redenen om linters toe te voegen aan HTML (alleen toegankelijkheidsdoeleinden kunnen nuttig zijn denk ik) en er zijn minder redenen om linters toe te voegen aan CSS (dat kan worden gereduceerd tot een code een opmaakcontrole).
hebt u een pluis gebruikt? Zo ja, vertel ons in welke taal en context en wat uw ervaring was.
Ik vond het persoonlijk leuk na enkele aanpassingen bij het gebruik van TypeScript.
Zoals altijd, Ik hoop dat je dit bericht leuk vindt en met vriendelijke groet,
Joel