Jokin aika sitten olin auttaa junior-kehittäjä, joka on näennäinen kysymys, hänet koodi, selvittää, mikä oli väärin se. Hän asensi nukkan ja latasi (Jumala tietää miksi) sille räätälöidyn sanakirjan. Valmistelin pienen testiympäristön ja näytin hänelle eron eri testien välillä, eri kohdissa ja joidenkin rajoitusten välillä (tässä pienessä ympäristössä).
Äskettäin puhuin testaus kollegan kanssa ja minä muistin tämän tarinan ja kertoi itsekin kirjoittaa postauksen, että se voisi olla mielenkiintoisia monille.,
mitä linnoitus on?
Linting on ohjelmallisten ja tyylillisten virheiden lähdekoodisi automaattinen tarkistaminen. Tämä tehdään nukkatyökalulla (alias linter). Nukkatyökalu on staattisen koodin perusanalysaattori.
termi linting alun perin peräisin Unix-apuohjelma C. On monia koodi puuvillalintterit saatavilla eri ohjelmointikieliä tänään.
Lint-ohjelmointi on eräänlainen automatisoitu tarkistus. Se voi tapahtua varhaisessa kehitysvaiheessa, ennen koodin tarkistamista ja testausta. Koska automatisoitu koodi tarkastuksia tehdä koodin tarkastelua ja testata prosesseja tehokkaammin., He vapauttavat kehittäjäsi keskittymään oikeisiin asioihin.
Monet automatisoidun testauksen työkaluja hyödyntää sisäänrakennettu linter heittää virheet, asettaa joitakin pisteet siitä, koodin laatua ja estää koota tai sijoittaa vaiheessa, jos tämä pistemäärä on pienempi kuin haluttu (automaattisesti tai keskeyttämällä prosessi heittää ilmoituksen manuaalisesti tarkistaa, jos tämä ”virheet” olisi paikattu vai ei).
mihin on tarkoitettu?
Lintingin tarkoituksena on vähentää virheitä ja parantaa devs-koodin yleistä laatua, nopeuttaa kehitystä ja vähentää kustannuksia löytämällä virheitä aikaisemmin.,
milloin Nukkaohjelmistoa kannattaa käyttää?
Jos tämä on sinulle uutta, saatat olla jossain määrin hyped kanssa tuoppeja tässä vaiheessa, mutta ne eivät ole ohjelmallisesti työkalu. Nukkaa on yksinkertaisesti ”scrapper”/file reader script tiedosto (yleensä json tai xml) ennalta (tai mukautetun) säännöt siitä, miten koodi on näyttää. Itse asiassa IDEs on sisäänrakennettu Nukkaa, joka heittää sinut virheen (eli jos soitat olematon menetelmä, tai jos yrität lisätä merkkijono arvo kokonaisluku muuttuja) tai varoitus (ts., jos ilmoitat muuttujan ehdollisen sisällä ja palautat muuttujan menetelmäsi lopussa). Mutta en puhu sisäänrakennettu koodi nukkaa, koska tämä puuvillalintterit ovat ”pehmeitä” ja salliva, muuten monet ihmiset eivät käytä niitä, IDEs, näemme myöhemmin, miksi.
Voit käyttää erityisiä Nukkaa, jos et sovi tähän lausunnot:
Kun käytät Tulkita Ohjelmointikieliä.
osa kielistä soveltuu paremmin koodilinnoitukseen kuin toiset. PHP, Python ja JavaScript tulkitaan kieliä, tämä tarkoittaa, että heiltä puuttuu kokoava vaihe*., Niinpä lint-ohjelmiston käyttö on tehokasta johdonmukaisen koodaustyylin varmistamisessa ja peruskoodausvirheiden ratkaisemisessa näissä tapauksissa.
mutta kun kyseessä ovat kootut kielet, kuten C ja C++, lint-ohjelmiston käyttäminen ei välttämättä riitä. C ja C++ ovat monimutkaisia ja saattavat vaatia kehittyneempää koodianalyysia.
* you may be shooting I compile JavaScript! mutta se ei ole totta. Nykyään front end käytämme työkaluja, kuten bundlers, lisäämällä joitakin javascript-työkaluja, jotka kulkevat meidän js joidenkin vaiheiden, kuten minify, ugglify, ofuscate. Jotkut näistä työkaluista myös poistaa käyttämättömän koodin sen ulostulo., Mutta mikään näistä asioista tarkoittaa, että kokoat javascript, koska lähtö on .JS-tiedosto joka tapauksessa; ei bytecode, ei assembler.
Se on totta, että voit muuntaa javascript osaksi web-kokoonpano, mutta se ei ole suora polku yhdestä toiseen, sinun täytyy muuntaa js jotain ”compilable” kuten C-koodia ja sitten koota sen osaksi web-kokoonpano.
Kun käytät Standardisääntöjä
Tämä on hieman hankala lausunto., On ohjelmointi kieli, et voi käyttää jotain, joka ei ole sisäänrakennettu oman ohjelmointikieli (joka ei ole totta ollenkaan, koska voit lisätä kirjastoja tai heittää järjestelmän komentoja ohjelmointikieliä, mutta joka tapauksessa Nukkaa ei ole mitään tekemistä sen kanssa, että niin…)
mitä Standardisäännöt tarkoittavat?
puitteiden käyttäminen sopii täällä mukavasti, sinun täytyy käyttää framework-sisäänrakennettuja menetelmiä halutun tuotoksen saavuttamiseksi.
joskus vakiosäännöt tarkoittavat muodikkaasti koodia., Tämä menetelmien ja kiertoteitä, jotka yhteisön toistaa kuin mantraa, kunnes he löytävät toinen muodikkaasti tapa tavoittaa tietyn tehtävän, tai kunnes joku julkinen kaiku kertoo yhteisön ”hei, analysoin tämän kiertoteitä ja minä huomaamaan, että on olemassa parempi tapa saavuttaa tämä tähän syistä” ja sitten yhteisön liikkuu.
kun tarpeesi ovat perus
Nukkatyökalut sopivat hyvin perusanalyysiin. Mutta jos tarvitset kehittyneempää analyysiä, sinun täytyy etsiä muualta (automatisoidut testausvälineet ja testivetoinen kehitys).
Where should I see a lint?
1., Automaattisia testejä (kutsumme heitä automatisoitu, koska ne virtaavat automaattisesti, mutta joku tarvitsee koodi testi jokaisen käytön tapauksessa app), kuten Cypress, voit lisätä nukkaa pisteet koodin laatua.
Tämä voi toimia kehityksen aikaa (kun dev osuu testi-painiketta) tai todennäköisesti deploy vaiheessa. Esimerkiksi, kun painat jotain master branch se voisi olla laukaista nostaa testit, mukaan lukien nukkaa, ja estää ottaa käyttöön (ja syyttää sinua), jos teit jotain väärin, sitten sinun täytyy korjata tai löytää vian (tämä ei tarkoita, että se on sinun syysi., Voisin työntää API, joka saa asiakkaasi kaatumaan saaden odottamattomia arvoja,ja tämä on minun vikani, ei sinun).
Tämä testeissä ei ole tarkoitus syyttää sinua, mutta auttaa osaksi kehitysprosessia, se on yleensä parempi löytää vika ennen sisällyttämällä pre-production vaiheessa, koska testi vika kuin löytää se yllätyksenä tuotantoon.
2. Isoissa projekteissa, yleensä isoissa yrityksissä., Jos olet erittäin iso yritys projektipäällikkö olisi kuten kaikki koodi näyttää sama (alustus), joten heillä on luultavasti nukkaa se, että jossain vaiheessa, jos olet lisännyt 4 välilyöntejä luetelmakohdassa jotain, mitä he haluavat, jossa on 2 ja että on syytä sinua, jos et julistaa menetelmä, jossa kameli tapauksessa esimerkiksi.,
olen löytää sävyjä junior devs yrittää taistella sitä vastaan, koska he pitävät joitakin erityisesti muotoilun, mutta ilman tätä työkaluja, tämä iso-ohjelmisto apps-näyttää frankensteinin hirviö tulevaisuudessa lisää vaikeuksia lukea kaikki osat tai jälkeen joitakin menetelmä polkuja ja luokka ohittaa. Ajattele sitä kuin lukisi kirjaa siitä, missä jokaisessa kappaleessa on erilainen kirjasinkoko, kirjasinperhe ja niin edelleen.
missä sitä ei saa käyttää?
Tämä kohta on niin helppo: älä käytä sitä dynaamisessa kontekstissa ja ohjelmoimattomissa kielissä.
1. Ensimmäinen on helppo ymmärtää., Jos olet dynaamisessa kontekstissa nukka (staattinen tarkistaja) ei koskaan tiedä lopputulosta ja syyttää sinua asioista, jotka ovat OK, lisään jonkin esimerkin seuraavasta kohdasta.
2. Tämän pitäisi kuulostaa naurettavalta, tarpeettomalta tai voit kertoa minulle ” missä käytät nukkaa, jos se ei ole ohjelmointikielellä?”
Mulder, siellä on HTML-ja CSS-linttereitä.
Yea.. – niin… Mutta miten?,
– he eivät ole puuvillalintterit totuus on, he ovat vain koodi-tammi, samalla voit tehdä w3c validator, mutta sen sijaan kopioimalla koodin suoraan validaattoriin, ne yleensä ajaa kehityksen aikaa syyttää sinua eri asioita perustuu jonkun lausunnon, joka on ärsyttävää, epätarkkoja ja ei todellakaan sovi nykyään käyttö tämän kaksi teknologiaa (tai kolme, jos lisäät SCSS), ja mikä tärkeintä, he eivät yleensä ole syy jokaisen lausuman, tai syistä, jotka ovat ristiriidassa pisteestä toiseen, tai syy on vanhentunut, tai syyt eivät ole sovellettavissa kaikkiin hankkeisiin., Siksi löydät ääniä ”unohda csslint, se on opinionated ja ei sovi projekti” kommentteja ja monia vastaavia muita internetissä.
jostain syystä löytyy koodinpätkiä, joita kutsutaan Lintereiksi, mutta ainakin he kertovat ”I’ am an opinionated code formatter”, kuten tämä .,
HTML nukkaa voisi olla hyödyllistä joskus, koska se pakottaa sinut lisää alt-määritteen kuvia ja muita saavutettavuutta ja hyviä käytäntöjä (Useimmat IDEs näkyy varoitus liian lisäämättä nukkaa, joka on parempi) mutta tämä ei estä sinua käyttämästä <span> kuin <p> tai muu huono html-käyttö.
Se myös ärsyttää, jos kirjoitat mallin osia typerä lausuntoja, kuten ”sinulla ei ole doctype-ilmoituksen, sinun ei tarvitse html, head, title eikä body., Ja voisit asia ”tietenkin, koska tämä tiedosto ladataan sisällä asiakirja, joka jo on tämä luokka”, mutta HTML nukkaa voi tietää sitä; Lints ovat staattisia nappuloita ja olet työskennellyt dynaaminen ympäristö, niin eteenpäin ja poistaa html nukkaa ollenkaan.
CSSLint on hieman erilainen, siellä ei ole asia, voit nukkaa täällä, voit kirjoittaa voimassa tai virheellinen CSS-mutta siinä kaikki.,
On olemassa hyviä käytäntöjä, CSS, joka seistä tehokkuutta ja nopeutta varten (se hyödyttää myös UX), toiset, että menee ylläpidettävyys, laajennettavuus ja luettavuutta varten (yleensä perustuu kehitys kokemus), toinen niistä seistä saavutettavuus (perustuu UI/UX tutkimukset ja selaimen rappaukset, näytön kontrasti testit ja niin). Mutta ei ole piste yhdistää se kaikki tulee linter ja kertoa devs vastaamaan kaikkia niitä käytäntöjä, ensinnäkin, koska siellä on ristiriitoja, joka tarvitsee ihmisen tehdä päätös käyttää yksi tai toisella.,
käytetään tapauksessa, jossa valita voitaisiin hoitaa se, että lisäämällä kaikki saavutettavuus CSS-koodi on havaittavasti lisätä koko -, lastaus-aika, ja ensimmäistä kertaa interaktiivinen mittareita, joten sinun yleensä valita vain saavutettavuus säännöt, joka sopii parhaiten asiakkaille säilyttäen hyvä suorituskyky.
– asetus typerä esimerkki siitä, itsepäinen sääntö CSSLint sanotaan, että haluan linear-gradient tausta sivuilleni tärkein lohko. CSSLint heittää varoituksen lineaarisen gradientin suorituskyvystä.,
tässä vaiheessa CSSLint haluatko poistaa lineaarisen gradientin, mutta mitkä ovat vaihtoehdot?
kuvan Käyttäminen on sävyjä kertaa vähemmän tehokas tavoitteen saavuttamista suunnittelu (ja myös vähentää visuaalinen laatu kaltevuus, ja se on vaikeampi muuttaa sopivaksi kaikki posible koot lohko).
joten mitä voimme tehdä? Yksinkertaisesti sivuuttaa CSSLint, koska se on itsepäinen, ja tämä ei tue mitään syytä.
lineaarisen gradientin lisäämisessä on ero verrattuna 42342 lineaarisen gradientin lisäämiseen samalle näkymälle., Muuten, jos tarvitset niitä, se on silti tehokkaampi kuin kuvien käyttö.
Voit myös löytää ristiriitaisia lausuntoja siitä niin:
”Älä käytä Tunnuksia muotoilu”. Syy on se, että siitä tulee ei-käyttökelpoinen sääntö.
ja
” Don ’t use adjoining classes”. En voinut kunnolla selvittää syy lukematta css-lint säännöt selitys ja syy on ”, Kun teknisesti sallittu CSS, nämä eivät ole käsitelty oikein Internet Explorer 6 ja aiemmin”.
olen jotain kerrottavaa CSSLint., Kukaan ei välitä IE 6 ja aikaisemmat, olemme vuonna 2020, 99% web-ohjelmisto tukee I. E. 11 niin paljon, joka julkaistiin 2013 ja on vähemmän kuin 3% käyttö.
toisaalta, missä Jumalan tähden on ilmaistu, että kaikki CSS-säännöt on voitava käyttää uudelleen samaan näkemykseen?
Jos sinulla on ainutlaatuinen tuote, web-sovellus, eli sinulla todennäköisesti on vain yksi navbar, vain yksi chat popup, jos mitään, vain yksi navigointipalkin logo ja vain yksi footer nimeäminen jotkut, miksi sinun täytyy lisätä se tyyli maailmanlaajuinen? Eikö se ole niin huono käytäntö, joka on vastoin kaikkia muita kieliä ympäri maailmaa?,
lisänä, sanotaan, että sinulla on 5 katselukertaa projektistasi. Jos sinulla on <nav> se todennäköisesti näkyy ne kaikki, niin sama tyyli voit laittaa alla #primary-navigation toimii 5 eri näkemyksiä. Eikö tämä ole uudelleenkäytettävyyden keino?
lisätä silliness ympärillä, että molemmat säännöt yhdessä, katso, miten se antaa sinulle vaikean tilanteen.,
Jos et voi käyttää tunnus muotoilu <nav class="dark-theme">, ja et voi lisätä vierekkäiset luokat<nav class="primary-navigation dark-theme">, miten voit hallita laajuus tyyli ja tehdä se paremmin ylläpidettävissä, ihmisen luettavissa ja miten hallita sitä lisätä java-script-tapahtuma kuuntelijoita, kun tarvitaan tehokas tapa?
Et yksinkertaisesti voi.
Mitä voisimme tehdä, semanttisesti oikea ja helppo säilyttää?, Katsotaanpa esimerkkinä:
Tässä on toinen lausunto, joka saa minut nauramaan vähäksi aikaa:
Vältä varauksettoman attribuuttivalitsimien ”Epäpäteviä attribuuttivalitsimien, kuten ottelun kaikki elementit ensin ja sitten tarkistaa niiden ominaisuuksia. Tämä tarkoittaa varauksetonta attribuuttivalitsimien on samat suoritusarvot kuin universaali valitsin (*)”
– rakkaani, tämä ei ole erilainen kuin mitä tapahtuu, kun käyttää luokan tai id, tai tag valitsin.
selaimen CSS-renderoinnin vaiheet ovat:
- domin rakentaminen., DOM on puun kaltainen tietorakenne, joka sisältää kaikki sivun HTML-solmut. Jokainen solmu sisältää tiedot siitä, että HTML-elementti (kuten attribuutteja, tunnukset ja luokat) Jos solmu on mitä tahansa HTML-elementtejä, kuten lasten, se myös korostaa niitä lapsen solmuja.
- Cssomin rakentaminen. Kun selain kohtaa CSS-tyylitiedoston (joko upotettu tai ulkoinen), se tarvitsee jäsentää tekstiä jotain, se voi käyttää tyyli ulkoasuja ja maalit. Tietorakenne, että selain kääntyy CSS osaksi on luovasti nimetty CSSOM.
- tuottaa Renderipuun., Lyhyesti sanottuna renderipuu sisältää kaikki tiedot, joita selain tarvitsee pikselien luomiseen sivulla. Selain pohjimmiltaan vie DOM ja CSSOM ja murskaa ne yhteen, poistamalla mitään, mikä ei ole vaikutusta sulatettu ulostulo.
- Layout and Painting.
Asettelun vaihe, selain keksii koko ja sijainti elementtejä (ei sulatettu vielä) ja sitten maalata vaiheessa se alkaa tuottaa pikseliä, että voimme visualisoida.,
Kuten näet, voit saada hieman performance bias, kun pesintä umpimähkään sinun valitsimet, kuten body>#main-content>.first-block .products-card p kuten voit luoda tarpeettomia lapsi solmut osaksi CSSOM, että täytyy sovittaa DOM ja tämä vie hieman enemmän aikaa kuin käyttämällä vain.products-card p, mutta koska meidän täytyy säilyttää tämä koodi ja luultavasti mittakaavassa se, meidän on soveltamisala sääntöjä niin sanotaan #main-content .products-card p.
Se on hyvä käytäntö, mutta en ole koskaan näki web-sovellus, jossa tarkempia valitsimet aiheuttavat kuorman nopeuden pullonkaula., Tämä yleensä johtuu iteroimalla yli ja uudestaan pitää sävyt käyttämätön koodi, että selaimen tulee lisätä osaksi CSSOM ja täytyy verrata DOM selvittää, jos se on OK, voit lisätä sen osaksi render puu vai ei.
tämän ja muita monia syitä, miksi et voi löytää artikkeleita selittää jokainen väärä kohta CSSLint, kuten tämä yksi, joka selittää asioita laajemmin kuin minä tässä.
Yhteenveto
Linterit ovat hyviä joillekin asioille ja huonoja toisille.,
Niitä voidaan myös muokata sopimaan joitakin projektin tarpeisiin tai jonkin yrityksen tai henkilön mieltymykset välttää näitä sääntöjä, jotka ovat itsepäinen ja lisäämällä muita hyödyllisiä sääntöjä, jotka sopivat projektin olet.
on monia syitä käyttää puuvillalintterit on tulkittava kielillä (on koottu niitä, IDE ja kääntäjä hoitaa tämän, mutta voit myös lisätä Nukkaa tarkistaa koodin muotoilua tai vain saada varoitukset, ennen kuin koota välttää odottaa, että kääntäjä havaitsee virheen tai päättyy tietää, jos kaikki on OK).,
on Olemassa muutamia syitä lisäämällä puuvillalintterit HTML (ainoastaan esteettömyyden kannalta voi olla hyödyllistä, luulen) ja siellä on vähemmän syitä lisäämällä puuvillalintterit CSS (joka voidaan vähentää koodin muotoilun tarkistus).
Oletko käyttänyt nukkaa? Jos olet, kerro meille, millä kielellä ja millä asiayhteydellä ja mikä oli kokemuksesi.
itse pidin siitä muutaman Tweakin jälkeen, kun käytin Typescriptiä.
kuten aina, hope you like this post ja Best regards,
Joel