néhány évvel ezelőtt segítettem egy junior fejlesztőt, akinek nyilvánvaló problémája van a kódján, hogy megtudja, mi volt a baj rajta. Telepített egy szöszöt, és letöltött (Isten tudja, miért) egy testreszabott szótárt. Készítettem egy kis tesztkörnyezetet, és megmutattam neki a különbséget a különböző tesztek között, különböző pontokon és bizonyos korlátokon (ezen a kis környezetben).
nemrég egy kollégával való tesztelésről beszéltem, és eszembe jutott ez az anekdota, és azt mondtam magamnak, hogy írjak egy bejegyzést erről, mivel sokak számára érdekes lehet.,
mi a linting?
a Linting a forráskód automatizált ellenőrzése programozási és stilisztikai hibák esetén. Ez egy szöszszerszám (más néven linter) használatával történik. A lint eszköz egy alapvető statikus kódelemző.
a linting kifejezés eredetileg a C Unix segédprogramból származik.
a Lint programozás az automatizált ellenőrzés egyik típusa. Ez történhet a fejlesztés korai szakaszában, a kódellenőrzés és a tesztelés előtt. Ennek oka, hogy az automatizált kódellenőrzések hatékonyabbá teszik a kódellenőrzési és tesztelési folyamatokat., És felszabadítják a fejlesztőket, hogy a megfelelő dolgokra összpontosítsanak.
Sok automatizált tesztelési eszközök előnyeit, beépített linter, hogy dobja a hibát, meg néhány pontszám arról, hogy a kód minősége, valamint blokkolja a fordítás, vagy egy telepíteni színpadon, ha ez az érték alacsonyabb, mint a kívánt (automatikusan vagy szüneteltetése a folyamat dobott egy értesítést, hogy kézzel ellenőrizze, hogy ezt a “hibát” kell javítani vagy nem).
mire szolgál?
a Linting célja a hibák csökkentése és a devs kód általános minőségének javítása, a fejlesztés felgyorsítása és a költségek csökkentése a korábbi hibák megtalálásával.,
mikor kell használni a Lint szoftvert?
Ha ez új az Ön számára, akkor lehet, hogy néhány kicsit felvillanyozott lints ezen a ponton, de ezek nem programagically eszköz. A lint egyszerűen egy “scrapper” / fájl olvasó script egy fájl (általában egy json vagy xml) előre meghatározott (vagy testreszabott) szabályok arról, hogy a kód kell kinéznie. Valójában az ide-knek van egy beépített Szöszje, amely hibát okoz (azaz ha nem létező módszert hív, vagy ha megpróbál egy karakterlánc értéket egész változóba hozzáadni) vagy figyelmeztetést (azaz, ha egy változót feltételesen belül deklarál, majd ezt a változót a módszer végén adja vissza). De nem a beépített kódszövegről beszélek, mivel ez a vonalzó “puha” és megengedő, különben sokan nem fogják használni ezeket az ide-ket, majd később meglátjuk, miért.
ha értelmezett programozási nyelveket használ, használhat egy adott Szöszöt, ha belefér ebbe a kijelentésbe:
.
egyes nyelvek jobban megfelelnek a kódszövésnek, mint mások. A PHP, A Python és a JavaScript nyelveket értelmezik, ez azt jelenti, hogy nincs fordítási fázisuk*., Tehát a lint szoftver használata hatékony a következetes kódolási stílus biztosításához, valamint az alapvető kódolási hibák megoldásához ezekben az esetekben.
de ha lefordított nyelvekről van szó, mint például a C és a C++, a lint szoftver használata nem elegendő. A C és a C++ összetett, és fejlettebb kódelemzést igényelhet.
* lehet, hogy kiabálva fordítom a Javascriptet! de valójában ez nem igaz. Manapság a front end-en olyan eszközöket használunk, mint a bundlerek, hozzáadunk néhány javascript-eszközt, amelyek bizonyos fázisok, például a minify, az ugglify, az ofuscate által átadják a js-t. Ezen eszközök némelyike a fel nem használt kódot is törli a kimenetén., De ez a dolog nem azt jelenti, hogy a javascript-t állítja össze, mivel a kimenet a lesz .JS fájl egyébként; nincs bytecode, nincs assembler.
igaz, hogy a JavaScriptet webes összeállítássá alakíthatja, de ez nem közvetlen út egyikről a másikra; a js-t valami “összeállítható” ilyen C-kódra kell konvertálnia, majd webes összeszerelésbe kell fordítania.
Ha szabványos szabályokat használ
Ez egy kicsit trükkös állítás., Egy programozási nyelv nem lesz képes használni valamit, ami nem beépített a programozási nyelv (ez nem igaz egyáltalán, mint akkor hozzá könyvtárak vagy dobja rendszer parancsokat programozási nyelvek, de egyébként Lint semmi köze, hogy így…)
milyen általános szabályok érvényesek?
a keretrendszer használata itt jól illeszkedik, a keretrendszer beépített módszereit kell használnia a kívánt kimenet eléréséhez.
néha a szokásos szabályok divatosan kódot jelentenek., Ez a módszertanok és megoldások, hogy a közösség ismétlődik, mint egy mantra, amíg nem találnak egy divatosan módon, hogy elérjék a cél egy adott feladat, vagy amíg valaki a nyilvános hatása azt mondja a közösségnek:” Hé, elemeztem ezt a megoldásokat, és úgy találom, hogy van egy jobb módja annak, hogy elérje ezt Ezen okok miatt”, majd a közösség mozog.
amikor az Ön igényei alapvetőek
a Lint eszközök nagyszerűek az alapvető elemzéshez. De ha kifinomultabb elemzésre van szüksége, máshol kell keresnie (automatizált tesztelési eszközök és tesztvezérelt fejlesztés).
hol kell látnom egy szöszöt?
1., Az automatizált tesztek (hívjuk őket automatizált, mert automatikusan fut, de valaki kell kódolni a teszt minden egyes felhasználási esetben egy app), mint a Cypress, akkor adjunk hozzá egy szöszt, hogy pont a kód minősége.
Ez futtatható fejlesztési idő (amikor a dev eléri a teszt gombot), vagy valószínűleg a telepítési szakaszban. Például, ha nyomja valami a mester ága lehet egy ravaszt, hogy emelje fel a vizsgálatok, beleértve a szösz, meg blokkolni a telepíteni (pedig hibáztatlak), ha valami rosszat tettél, akkor meg kell javítani, vagy keresse meg a hibát (ez nem jelenti azt, hogy a te hibád., Én is nyomja egy API, ami az ügyfél összeomlik fogadása váratlan értékeket, és ez lesz az én hibám, nem a tiéd).
Ez a teszt nem arra szolgál, hogy hibáztasson, hanem hogy segítsen a fejlesztési folyamatban, általában jobb, ha hibát talál, mielőtt a gyártás előtti szakaszba integrálná a teszt meghibásodása miatt, mint meglepve a gyártásba.
2. Nagy projekteken, általában nagyvállalatokon., Ha egy nagyon nagy cég a projektmenedzser, mint a kód ugyanaz (formázás), így valószínűleg a szösz ez valahol a ponton, ha a hozzáadott 4 fehér terek francia valamit akarnak, 2, illetve, hogy fog hibáztatni, ha nem kijelentem, egy módszer a teve esetben például.,
találom hangok junior fejlesztőknek próbál harcolni ez ellen, mert ők, mint egy adott formázás, de anélkül, hogy ez a szerszám, ez a nagy szoftver alkalmazások fog kinézni, mint egy frankenstein-szörny a jövőben egyre nagyobb a nehézségi az olvasás minden alkatrész vagy a következő néhány módszer utak, osztály felülír. Gondolj rá, mint olvasni egy könyvet, ahol minden bekezdés van egy másik betűméret, font-család, stb.
hol ne használja?
Ez a pont olyan egyszerű: ne használja dinamikus kontextusban és nem programozási nyelveken.
1. Az első könnyen érthető., Ha egy dinamikus kontextusban a szöszt (statikus ellenőrző) soha nem fogja tudni a végeredményt, majd hibáztatni a dolgokat, hogy rendben van, majd adjunk hozzá néhány példát a következő pont.
2. Ennek nevetségesnek, feleslegesnek kell lennie, vagy elmondhatja nekem: “hol használsz egy szöszöt, ha nem programozási nyelven van?”
, vannak HTML és CSS linterek odakint.
Igen.. um… De hogyan?,
Nos, nem linters az igazság az, hogy ők csak a kód-ellenőrzők, ugyanaz a w3c validator, de ehelyett a másolás a kódot egy ellenőr, általában fut a fejlesztési idő hibáztat, más dolgok alapján valakinek véleménye, ami bosszantó, pontatlan, de nagyon nem illik manapság használat ezt a két technológia (vagy három, ha hozzá SCSS), de a legfontosabb, hogy általában nincs oka minden nyilatkozatot, vagy az oka ellentmond a lényeg, hogy egy másik, vagy ennek az az oka, elavult, vagy az okok nem alkalmazható minden projektek., Ez az, amiért meg fogja találni hangok “felejtsd el CSSLint, ez nagyképű, és nem illik a projekt” megjegyzéseket, valamint sok hasonló mások az Interneten keresztül.
talál néhány olyan kódot, amelyet valamilyen oknál fogva Lintereknek hívnak, de legalább azt mondják, hogy “én vagyok egy nagyképű kódformázó”, mint ez .,
HTML-lint hasznos lehet néha, mivel kényszeríteni fogják, hogy adjunk egy alt attribútum a képeket, egyéb elérhetőség, illetve a jó gyakorlatok (a Legtöbb IDEs azt mutatja, hogy egy figyelmeztetés is hozzáadása nélkül a szösz, ami jobb) de ez nem akadályozza meg abban, hogy használja a <span>, mint <o> vagy más rossz html-használat.
Ez is bosszantja Önt, ha sablonösszetevőket ír olyan buta kijelentésekkel ,mint például: “nincs doctype nyilatkozat, nincs html, fej, cím vagy testcímke., És lehet, hogy “természetesen, mivel ez a fájl betöltődik egy olyan dokumentumba, amely már rendelkezik ezzel a címkével” , de a HTML lint nem tudja; a lint statikus dáma, és dinamikus környezetben dolgozik, tehát lépjen tovább és törölje a html lint-et.
A CSSLint egy kicsit más, itt egyébként nem lehet semmit szöszölni, érvényes vagy érvénytelen CSS-t írhat, de ez minden.,
vannak jó gyakorlatok a CSS-t, hogy álljon a hatékonyság, a sebesség célokra (is előny, hogy UX), mások, hogy megy a karbantartási, skálázhatóság, illetve olvashatóság céljából (általában alapuló fejlesztési tapasztalat), másik is álljon a kisegítő alapján (UI/UX vizsgálatokat, valamint a böngésző vakolatok, képernyő kontraszt tesztek stb). De nincs értelme összevonni az egészet egy linterré, és azt mondani a fejlesztőknek, hogy illeszkedjenek ezekhez a gyakorlatokhoz, mindenekelőtt azért, mert vannak olyan ellentmondások, amelyeknek egy embernek szüksége van arra, hogy döntést hozzon az egyik vagy másik használatáról.,
Egy használati eset, ahol választani lehet foglalkozott azzal a ténnyel, hogy hozzátéve, hogy mind a hozzáférhetőség CSS kód observably növeli a méretét, a betöltési idő, mikor először interaktív mutatókat, így általában választja, csak a kisegítő szabály, amely illik a legjobban, hogy az ügyfelek megtartása mellett jó teljesítményt.
egy buta példa beállításához egy nagyképű szabályról a CSSLint-en tegyük fel, hogy szeretnék egy lineáris gradienst háttérként a Kezdőlap főblokkjában. A CSSLint figyelmeztetést küld a lineáris gradiens teljesítményről.,
ezen a ponton a CSSLint azt akarja, hogy törölje a lineáris gradienst, de mik az alternatívák?
a kép használata kevésbé lesz hatékony a céltervezés eléréséhez (valamint csökkenti a gradiens vizuális minőségét, és megnehezíti az átméretezést, hogy illeszkedjen a blokk minden pozible méretéhez).
tehát mit tehetünk? Egyszerűen figyelmen kívül hagyja a CSSLint, mert nagyképű, és ez nem támogatja semmilyen okból.
különbség van egy lineáris-gradiens vs hozzáadásával 42342 lineáris-gradiens ugyanazon a nézeten., Egyébként, ha szüksége van rájuk, még mindig hatékonyabb lesz, mint a képek használata.
ellentmondásos kijelentéseket is találhat rajta:
“ne használjon azonosítókat a stílushoz”. Ennek oka az, hogy nem használható szabály lesz.
és
“ne használja a szomszédos osztályokat”. Nem tudtam megfelelően kitalálni az okot anélkül, hogy elolvastam volna a css lint szabályok magyarázatát, ennek oka az, hogy “bár technikailag megengedett a CSS-ben, ezeket az Internet Explorer 6 vagy korábbi nem kezeli megfelelően”.
van valami, amit el kell mondanom CSSLint., Senkit sem érdekel az IE 6 vagy korábbi, 2020-ban vagyunk, a webes szoftverek 99% – a támogatja az I. E. 11-et, amelyet egyébként 2013-ban adtak ki, és kevesebb, mint 3% – os felhasználással rendelkezik.
másrészről, hol az Isten szerelmére, azt fejezik ki, hogy minden CSS szabályt újra kell használni ugyanazon a nézeten?
Ha van egy egyedi elem a web app, azaz akkor valószínűleg csak egy navbar, csak egy chat felugró ha van, csak egy navbar logo és csak egy lábléc elnevezési néhány, miért kell hozzá ez a stílus globális? Nem olyan rossz gyakorlat, amely ellentétes a világ minden más nyelvével?,
kiegészítésként tegyük fel, hogy 5 nézete van a projektről. Ha van <nav> valószínűleg mindegyiken megjelenik, tehát ugyanaz a stílus, amelyet a #primary-navigation alatt helyez el, 5 különböző nézeten dolgozik. Ez nem az újrafelhasználhatóság egyik módja?
ahhoz, hogy növelje a ostobaságot, hogy mindkét szabály együtt van, nézze meg, hogyan engedi meg a nehéz helyzetet.,
ha nem tudja használni az id-t a stílushoz <nav class="dark-theme">, és nem adhat hozzá szomszédos osztályokat <nav class="primary-navigation dark-theme">, hogyan fogja kezelni, hogy hatékony módon hozzáadja a java-script esemény hallgatóit?
egyszerűen nem lehet.
mit tehetünk szemantikailag helyes és könnyen karbantartható?, Nézzünk egy példát:
ez Itt egy nyilatkozatot, hogy megnevettetsz egy darabig:
Kerülje a képzetlen attribútum választók “Képzetlen attribútum választók, például , minden mérkőzés elemek első, majd a tulajdonságok. Ez azt jelenti, hogy a képzetlen attribútumválasztók ugyanolyan teljesítményjellemzőkkel rendelkeznek, mint az univerzális választó (*)”
kedvesem, ez nem különbözik attól, ami az osztály, az id vagy a tag választó használatakor történik.
a böngésző CSS megjelenítésének szakaszai a következők:
- A DOM felépítése., A DOM egy fa-szerű adatstruktúra, amely az oldal összes HTML csomópontját tartalmazza. Minden csomópont tartalmazza az adott HTML-elem adatait (például attribútumok, azonosítók és osztályok) ha a csomópontnak bármilyen HTML-eleme van gyermekként, akkor ezekre a gyermek csomópontokra is mutat.
- a CSSOM felépítése. Amikor a böngésző CSS stíluslappal találkozik (akár beágyazott, akár külső), akkor a szöveget át kell értelmeznie valamibe, amit stíluselrendezésekhez és festékekhez használhat. Az adatstruktúrát, amelyet a böngésző CSS-be alakít, kreatívan CSSOM-nak nevezik.
- Render fa létrehozása., Röviden, a render fa tartalmazza az összes információt, amely a böngésző számára szükséges ahhoz, hogy képpontokat hozzon létre az oldalon. A böngésző alapvetően veszi a DOM és CSSOM és squashes őket együtt, eltávolítva mindent, ami nem lesz hatással a renderelt kimenet.
- elrendezés és festés.
Az elrendezés fázisában a böngésző kiszámítja az elemek méretét és helyzetét (még semmi nem jelenik meg), majd a paint lépésben elkezdi generálni a megjelenített képpontokat.,
Mint látható, akkor is kap egy kis teljesítmény elfogultság, amikor fészkelő válogatás nélkül a választók, mint a body>#main-content>.first-block .products-card p mint generál felesleges gyermek csomópontok a CSSOM, hogy kell, hogy megfeleljen a DOM-mal, ez egy kicsit több idő, mint használatával egyszerűen.products-card p, de fenn kell tartanunk ezt a kódot valószínűleg méretezni, meg kell hatálya a szabályokat, így mondjuk #main-content .products-card p.
Ez egy jó gyakorlat, de még soha nem láttam olyan webes alkalmazást, amelyben a specifikusabb szelektorok terhelési sebesség szűk keresztmetszetet okoznak., Ezt általában az okozza, hogy újra és újra iterálja a fel nem használt kód hangjait, amelyeket a böngésző hozzáad a CSSOM-hoz, és össze kell hasonlítania a DOM-val, hogy kiderítse, rendben van-e hozzáadni a render fához vagy sem.
ezért és más okok miatt sok olyan cikk található, amelyek a CSSLint minden rossz pontját magyarázzák, mint ez, amely átfogóbb módon magyarázza a dolgokat,mint itt.
összefoglaló
a Linterek bizonyos dolgokra jók, mások számára pedig rosszak.,
szerkeszthetők úgy is, hogy illeszkedjenek bizonyos projektigényekhez, vagy valamilyen vállalati vagy személyes preferenciához, hogy elkerüljék ezeket a nagyképű szabályokat, és hozzáadjanak más értékes szabályokat, amelyek illeszkednek a projekthez.
kevés oka van annak, hogy a linkereket HTML-be hozzuk (csak a hozzáférhetőség szempontjából hasznos lehet), és kevesebb oka van annak, hogy a CSS-en linkeket adunk hozzá (ez csökkenthető a formázási ellenőrző kódra).
használt egy Szöszöt? Ha igen, mondja el, hogy milyen nyelven és kontextusban, és mi volt a tapasztalata.
személy szerint tetszett, miután néhány csíp használatakor TypeScript.
mint mindig, remélem tetszik ez a bejegyzés, üdvözlettel,
Joel