Majdnem mindig lefogadhatod, hogy egy jó írás jótékonykodott a jó szerkesztésen. Ebből a szempontból a kód nem különbözik a prózától. Az egyik előny, amit fejlesztőként és programozóként élvezünk, a munkafolyamatainkba beépíthető szerkesztők, vagyis kódlinterek.

A linterezés az a cselekedet vagy folyamat, amelynek során a kódot bármilyen hibára ellenőrizzük. Sokféle gondolat létezik arra vonatkozóan, hogyan lehet optimalizálni egy adott kódrészlet hatékonyságát. De annak ellenőrzése, hogy biztosan hibátlan-e és megfelel-e egy adott stílusirányelvnek, az alapszintet jelenti. Néha ez a konzisztencia és az olvashatóság kérdése, néha pedig az, hogy a kód egyáltalán futtatható legyen.

A JavaScript lintinggel kapcsolatban van egy maroknyi eszköz, amely kiemelkedik a többi közül. Nézzünk meg négy lintert, amelyek segíthetnek a szűretési folyamat elindításában vagy finomításában: JSLint, standardJS, JSHint és ESLint.

JSLint

A JSLintet 2002-ben hozta létre Douglas Crockford, aki egyben a JavaScriptről szóló vitathatatlanul egyik legjobb könyvet is írta. A JSLint egyszerűséget és gyorsaságot hoz. Ugyanakkor nagyon véleményes is, ami lehet áldás vagy átok.

A JSLint egy egyoldalas oldalból áll, amelyet egy szövegmező ural, ahová beilleszthetjük a kódunkat. Kattintson a ‘JSLint’ gombra, és a szövegmező alatt megjelenik minden stilisztikai, szintaktikai vagy egyéb hiba. A szövegmező alatt egy kis lista található az opciókról, amelyek jelölőnégyzetekkel konfigurálhatók. Az opciók között szerepel az extra szóközök tűrése, a ‘this’ kulcsszó használata (amit Crockford az előadásaiban nem javasol) és a Node.js beillesztése.

Ha nem kötelezi magát semmilyen stílusirányzatra, és szeretne egy megbízható forrást, amely ellenőrzi a kódját, a JSLint egy nagyszerű lehetőség. Különösen hatékony a kódrészletek teszteléséhez, vagy ha kis projektek – esetleg egy egyoldalas statikus webhely, amely csak egy JavaScript-fájlt tartalmaz – gyors ellenőrzésére keresel megoldást.

standardJS

Kizárólag a GitHub csillagai alapján a standardJS a legnépszerűbb opció, közel 19 000 csillaggal. Teljesen véleményes, ami azt jelenti, hogy egyáltalán nem testreszabható. De ha nem kötelezi el magát semmilyen konkrét stílusirányzathoz, ez áldás lehet. Node CLI formájában érkezik, és globálisan vagy fejlesztési függőségként telepíthető a terminál vagy a választott parancssor segítségével:

$ npm install standard --global// or$ npm install standard --save-dev

Mivel a standardJS-nek előfeltétele a Node és az npm, és mivel parancssorból vagy npm szkript segítségével futtatható, a lécet kissé megemeli a JSLint szintjéhez képest. De mivel nem konfigurálható, más miatt nem nagyon kell aggódnod. A parancssorból egyszavas parancsként futtathatod, és minden .js kiterjesztésű fájlt ellenőrizni fog az aktuális munkakönyvtáradban.

Minden talált hibát kiír a terminálodra vagy a parancssorba. A standardJS dokumentációból ehhez a példához hasonló kimenetre számíthat:

$ standardError: Use JavaScript Standard Stylelib/torrent.js:950:11: Expected '===' and instead saw '=='.

Ha meg kell adnia egy fájlt vagy könyvtárat, akkor az elérési utat is megadhatja argumentumként, és használhat vadkártyákat. A program elfogadja a vadkártyákat is. Ebben a példában a standardJS a src könyvtárban és annak alkönyvtáraiban lévő JavaScript-fájlokat fogja megkeresni és lintelni:

$ standard "src/**/*.js" --fix

A --fix jelző a fájl elérési útja után a hibák automatikus javításának lehetősége, amint megtaláljuk őket. Ez nagy időmegtakarítást jelenthet, de remek tanulási gyakorlat is lehet, ha magad javítod a hibákat.

Ha szeretnéd felfedezni a standardJS által használt konvenciókat és szabályokat, mielőtt eldöntenéd, hogy használod-e, egy teljes listát itt találsz. A StandardJS remek választás azok számára, akik egy gyors és megbízható módot keresnek arra, hogy egy JavaScript linterrel kezdjenek el dolgozni.

JSHint

A JSHint a JSLint elágazásaként indult. A cél egy jobban konfigurálható linter elkészítése volt. Ha eddig a standardJS-t vagy egy másik véleményes lintert használtál, és szeretnéd elkezdeni a saját linting szabályaid testreszabását, a JSHint lehet, hogy neked való. A fent említett linterek legtöbb előnyével rendelkezik, és még többel is.

A JSLinthez hasonlóan a JSHint kezdőlapja is tartalmaz egy szövegmezőt, ahová beillesztheti a kódot. A szövegmezőtől jobbra található Metrics mező valós időben frissül a beírás közben, és egy futó statisztikai listát számol össze a kódodról, például azt, hogy hány függvényt tartalmaz. Természetesen megjeleníti a talált linting hibákat is.

Ha nem tetszik a másolás/beillesztés módszertana, és be akarod építeni a projektedbe, a JSHint globálisan vagy a projekt függőségeként telepíthető az npm segítségével:

$ npm install jshint --global// or$ npm install jshint --save-dev

A telepítés után a CLI-t használod a kódod lintingelésére. Íme két példaparancs, amelyek egy fájlt, illetve egy könyvtárat ellenőriznek:

$ jshint index.js// or$ jshint src/

Az első példában a JSHint a index.js fájlt fogja lintelni, a másodikban pedig rekurzívan átnézi a ‘src/’ könyvtárat, és linteli a talált JavaScript fájlokat. A JSHint minden talált hibát kiír a terminálba.

Ha nem érdekel a testreszabás, a JSHint a fenti példákban leírtak szerint is használható, és remekül fog működni. Innentől kezdve azonban a bonyolultság jelentősen megnőhet, mivel a JSHint teljesen konfigurálható, és egy API-t is kitesz, vagyis JavaScript-modulként használható a saját JavaScript-fájljaidban.

Egy egyéni konfiguráció, amelyet egy .jshintrc nevű fájlban kell tárolni, így nézhet ki:

{"esversion": 5,"eqeqeq": true,"strict": true}

Ez a példa, fentről lefelé haladva, az ECMAScript verzióját 5-ösre állítja, három egyenlőségjel használatát követeli meg ( === vagy !==) a kettővel szemben (== vagy !=) az értékek összehasonlításakor, és szigorú módot érvényesít. Az egyéni konfigurációkat a .jshintrc fájl elérési útjának a -- config flag mögött történő megadásával a parancssorban, vagy a projektek package.json fájljában a ‘jshintConfig’ attribútumként történő deklarálásával lehet beépíteni. A JSHint az alapértelmezett beállításait fogja használni minden olyan szabályhoz, amelyet nem szabsz testre.

A parancssori beállítás így nézhet ki:

// looks for '.jshintrc' in the current directory$ jshint --config './.jshintrc'

Az package.json beállítás pedig így nézhet ki:

{ "jshintConfig": { "esversion": 5, "eqeqeq": true, "strict": true }}

Ezek az alapok segítségével elindulhatsz a saját linting szabályaid testreszabásának útján a JSHint segítségével. Ha ennél többre vágysz, a hivatalos dokumentáció kimerítő leírást tartalmaz arról, hogyan használd a JSHint API-t, és hogyan lehet a saját igényeidhez igazítani.

ESLint

A GitHub csillagoktól eltekintve, ha a JavaScript lintingről van szó, az ESLint valószínűleg az a linter, amelyet a legtöbben látnak a természetben, és sokak számára ez lesz a cél. Saját dokumentációjában a JavaScript elemzésére használt módszerek tekintetében a JSLinthez és a JSHinthez hasonlítja magát. És a JSHinthez hasonlóan az alapértelmezett beállítások használatával könnyedén belevághatsz, és a preferenciáid vagy igényeid változásával testreszabhatod.

Az ESLint telepítése globálisan vagy fejlesztési függőségként:

$ npm install eslint --save-dev// or$ npm install eslint --global

Ha globálisan telepíted az ESLintet, a konfigurációi minden olyan projektfájlra érvényesek lesznek, amellyel szemben futtatod. Ha azonban különböző konfigurációkat szeretne különböző projektekhez, akkor telepítheti fejlesztői függőségként, és minden projekthez külön konfigurációs fájlt hozhat létre. Ne feledje, hogy ha az ESLintet nem globálisan, hanem projektfüggőségként telepíti, akkor a futtatható programot a node_modules mappából kell futtatnia a következőképpen:

$ ./node_modules/.bin/eslint --init

A fenti parancs futtatásakor egy kérdéssorozat végigvezet az ESLint konfigurálásán. (Megjegyzés: Függetlenül attól, hogy mennyire tervezi a linting szabályainak testreszabását, ezzel a lépéssel kell kezdenie, mert az ESLintnek szüksége van a .eslintrc fájlra, amelyet ez a folyamat fog létrehozni, mielőtt a kódját lintelni tudja.)

Az első kérdés, amelyet feltesznek önnek, az ESLint konfigurálása. Három lehetőséged van: használhatsz egy népszerű stílus útmutatót, válaszolhatsz a stílusoddal kapcsolatos kérdésekre, vagy hagyhatod, hogy az ESLint konfigurálja magát helyetted azáltal, hogy megvizsgálja a fájljaidat, hogy eldöntse, hogyan állítsa be a szabályokat. Ha a saját konfigurálás lehetősége rögtön ijesztőnek tűnik, akkor egy népszerű, néhány ismert szervezet által kifejlesztett stíluskalauz használatához folyamodhat.

Függetlenül attól, hogy melyik utat választja, az ESLint az Ön válaszai alapján létrehoz egy .eslintrc nevű fájlt az aktuális munkakönyvtárban. Ezt a fájlt fogja módosítani, ha a későbbiekben változtatni akar a linting szabályokon.

Itt egy JSON formátumú .eslintrc példafájl, amely az alapértelmezett Airbnb JavaScript stílusszabályokat használja, és két egyéni szabályt tartalmaz a strict mód kikapcsolására és a console.log() utasítások engedélyezésére:

{ "extends": "airbnb-base", "rules": { "strict": "off", "no-console": "off" }}

Ha úgy dönt, hogy válaszol a stílusára vonatkozó kérdésekre, olyan dolgokat fog megkérdezni, mint hogy melyik ECMAScript verziót használja, hogy a tabulátorokat vagy a szóközöket, a pontosvesszőket vagy sem, és hogy használ-e JSX-et és/vagy Reactot. Az ESLint out-of-the-box React támogatása és a kiegészítő bővítmények valószínűleg a legjobb választássá teszik a React fejlesztők számára. Legalábbis azok számára, akik még csak most kezdik a lintinget.

Az ESLint telepítése és egy .eslintrc fájl generálása után a CLI segítségével elkezdheti a kódja lintingelését. Az ESLint alapértelmezés szerint keresi a .eslintrc fájlt, így nem kell semmilyen konfigurációt megadni a parancssorban. De különböző zászlókkal megváltoztathatja az ESLint viselkedését. Az alábbi példában a -- quiet flag azt mondja az ESLintnek, hogy csak a hibákat jelenítse meg, nem pedig a figyelmeztetést és a hibákat is. A --fix flag arra utasítja, hogy a talált hibákat próbálja meg automatikusan kijavítani.

// run eslint against file1.js$ ./node_modules/.bin/eslint file1.js// run eslint against file1.js and file2.js with flags to modify behavior$ ./node_modules/.bin/eslint file1.js file2.js --quiet --fix

A többi tárgyalt CLI-hez hasonlóan, szükség esetén a konkrét fájlnevek helyett használhat vadkártyákat és fájlútvonalakat. Bár az ESLint nagymértékben konfigurálható, megkönnyíti a tanulási folyamatot azzal, hogy az alapértelmezett konfigurációs módszerhez egy könnyen megközelíthető beállítási útmutatót használ. Ha igazán bele akar ásni a testreszabásokba, a hivatalos dokumentáció nagyszerű magyarázatokat tartalmaz mindarról, amit az ESLint segítségével megtehet.

Következő lépések és következtetés

Összefoglalva:

  • A JSLint kiválóan alkalmas snippetek vagy egyes fájlok ellenőrzésére. Egyik lehetséges hátránya, hogy nem alkalmas nagy projektekhez.
  • AStandardJS ideális azok számára, akik kevés vagy semmi gonddal szeretnének belevágni és/vagy beépíteni egy lintert a munkafolyamatokba és build scriptekbe. De, nem konfigurálható. Így ha egyéni szabályokat kell készítenie, akkor valószínűleg a JSHint vagy az ESLint felé kell fordulnia.
  • A JSHint szintén telepíthető az npm-en keresztül, és a linting szabályai teljesen konfigurálhatók. Ez lehet jó vagy rossz, az igényeidtől és a készségszintedtől függően. Kezdheted az alapértelmezett szabályokkal, és szükség szerint testre szabhatod. Egy egyoldalas oldallal is rendelkezik, amelyet szippletek vagy egyes fájlok lintelésére használhat.
  • ESLint az npm-en keresztül telepíthető és a munkafolyamatokba építhető, akárcsak a JSHint. CLI-jének kérdés-felelet formátuma pedig segíthet a tanulásban a kezdetek során. Kész formában tartalmazza az iparági szabványos, nyílt forráskódú stílusirányzatokat és linting-szabályokat, amelyek bármely projektre alkalmazhatók.

Az általunk vizsgált négy linter mindegyike megbízható és jó hírű, mivel a webfejlesztői közösség jól ismert emberei és szervezetei használják és fejlesztik. Bárki jól járna bármelyikükkel. Ha elsajátította az ebben a cikkben tárgyalt alapokat, a következő nagyszerű lépés az lenne, ha megtanulná, hogyan integrálhatja őket tovább a munkafolyamatába az npm szkriptek vagy egy olyan bundler, mint a Webpack segítségével.

Minden eszköz csak annyira jó, amennyire használjuk. Ez igaz a linterekre és az általuk tökéletesíteni segített kódra is. Még ha egyedül fejleszt, és nem kell aggódnia a kód konzisztenciája miatt egy fejlesztői csapatban, akkor is hasznát veheti egy beépített szerkesztőnek. Ez egy hihetetlenül hatékony módja annak, hogy megtanuljon helyesen JavaScriptet írni. Függetlenül attól, hogy milyen lektort használ, a lektor használata csak segíthet. Fogadhatsz rá, hogy a kódod minősége javulni fog, ahogy a fejlesztői képességeid is.

LogRocket: JavaScript hibák könnyebb hibakeresése a kontextus megértésével

A kód hibakeresése mindig fárasztó feladat. De minél jobban megérted a hibákat, annál könnyebb kijavítani őket.

A LogRocket segítségével új és egyedi módon értheted meg ezeket a hibákat. Frontend monitoring megoldásunk nyomon követi a felhasználók JavaScript frontendjeivel való kapcsolatát, így pontosan megtudhatja, hogy mit tett a felhasználó, ami hibához vezetett.

LogRocket Dashboard Free Trial Banner

A LogRocket rögzíti a konzolnaplókat, az oldal betöltési idejét, a stacktraces-t, a lassú hálózati kéréseket/válaszokat fejlécekkel + testekkel, a böngésző metaadatait és az egyéni naplókat. JavaScript kódja hatásának megértése soha nem lesz egyszerűbb!

Próbálja ki ingyenesen.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.