Levegő belélegzése az AirBnB JavaScript stílusútmutatójába

Senki sem indul ki csúnya, következetlen stílusú kódok írására. Valahogy megtörténik.

Még a projekt egyetlen fejlesztőjeként is, minél több idő telik el, és minél több kódot fordítasz ki, annál nehezebb fenntartani az egységes kódstílust.

Ezért kell egy stílus útmutató.

Közvetlenül tapasztaltam, mennyivel több csapat képes teljesíteni egy stílus útmutató elfogadása után.

A nap folyamán már nem kell kevés stílusbecsléssel élnie. Csak olvassa el a stílus útmutatót.

És amikor egy csapattársnak karbantartania kell a kódját, akkor ez egy tiszta kód, amelyet el tudnak olvasni és megértenek.

A stílusismertető elfogadása az egyik legegyszerűbb dolog, amelyet megtehetsz a kódod karbantarthatóságának növelése érdekében - ami végső soron növeli csapatod termelékenységét. Tehát vizsgáljuk meg ennek legnépszerűbb módját.

Írja be az AirBnB + ESLint parancsot

A JavaScript ökoszisztéma sokféle eszközt és stílus útmutatót kínál. Ez senkit sem lephet meg. a JavaScript használatával sok mindenre számíthatunk.

Az ökoszisztéma érlelődésével azonban a tapasztalt fejlesztők a megszilárdultabb ökoszisztémák által kínált dolgok „szokásos módjára” vágyakoznak.

Természetesen örömmel tölthet el néhány napot a JavaScript ökoszisztéma felfedezésével és a különböző eszközök összehasonlításával, de megpróbálok spórolni egy kis időt : Az ESLint a legnépszerűbb JavaScript szöszmötlő eszköz, az AirBnB stílusútmutatója pedig a legszélesebb körben használt stílus útmutató.

Az ESLint projektbe történő felvételével kapcsolatos további részletekért lásd ezt a linket.

Ha ezt a négyzetet elhagyta, az npm csomag telepítésével konfigurálhatja a projektet az AirBnB stílus útmutatójának betartatására:

npm install --save-dev eslint-config-airbnb

Adja hozzá a következő sort az .eslintrc fájljához

"extends": "airbnb"

És voilà! A kódodra most a legnépszerűbb JavaScript stílus útmutató szabályai vonatkoznak. Boldog kódolást!

A szabványok túlértékeltek

Bár egyetértek a stílus útmutató legtöbb szabályával, itt van egy lista az általam összeállított felülírásokról. Így néznek ki a .eslintrc fájlok a projektek gyökérmappáiban:

Hadd magyarázzam el részletesen az egyes testreszabások mögött álló érvelést.

Behúzás

A VS űrháború lapjai tönkretehetik a barátságokat, sőt szabotálhatják a romantikus kapcsolatokat.

Inkább behúzom a 4-es kód szóközeimet, annak ellenére, hogy a kint élő konfigok döntő többsége inkább a 2-es behúzást részesíti előnyben.

Az az érvelésem, hogy a tiszta kód megírásához a nagyobb behúzások jobb vizuális ábrázolást nyújtanak arról, hogy a fészkelés milyen mélyen van a funkcióiban, és hány különböző ága van.

Nem szabad feltétlenül 3 vagy 4 rétegnél mélyebb kódot fészkelnie egy JavaScript fájlban (ez egy kódszag). Tehát 4 szóközzel jobb olvashatóságot kínál, miközben megőrzi az egyéb szabályokat, például a kódot soronként 80 vagy 120 karakteres korláton belül tartja.

A behúzás egyike azoknak a szabályoknak, amelyek több „levegőt” lehelnek az AirBnB alapértelmezett stílusútmutatójába. Ennek eredményeként a kód nem tolong annyira a szerkesztő bal oldalán.

Távolság

Valószínűleg ez a legnagyobb eltérés a színvonaltól. Utálom a zsúfolt kódot. Több mint 2 éve kezdtem el kódot írni extra szóközökkel, és soha nem néztem vissza.

Tehát mit jelentenek ezek a szabályok? Nos, nézze meg a következő kódot. Műszakilag tiszteletben tartja az AirBnB hivatalos stíluskalauzának szabályait.

Tudom, ez egy kicsit zavaró. Megpróbáltam közepes komplexitású függvényt keresni az egyik kódbázisomról, de sokat el kellett tévesztenem, ezért ne próbálja megérteni a kód mögött rejlő logikát (mert nincs). Csak próbáld meg elolvasni. Próbáljon összpontosítani például azokra a változókra, amelyeket több helyen használnak, amikor paramétereket adnak át a függvényeknek, és hol vannak a függvényhívások.

Most nézze meg ugyanazt a kódot, de az alkalmazott extra távolságszabályokkal:

Nem azt mondom, hogy most már jól olvasható, de könnyebben meg tudja határozni, hogy hol küldtek paramétereket a függvényekhez - különösen a curry függvények környékén.

Ellenőrizze a két példában a 2- és 4-tagú behúzás közötti különbséget is.

Eleinte ezek a technikák nem tűnhetnek nagy fejlődésnek. Javaslom, próbálja ki őket. Azt hiszem, hamar megtapasztalja, milyen különbség van ez.

Idézet háborúk

Noha az első két kategóriának egyértelmű érvei voltak, el kell mondanom, hogy az egy vagy kettős idézőjel döntése nagyon szubjektív.

A dupla idézetekkel kapcsolatos preferenciám valószínűleg abból adódik, hogy sokat dolgoztam a React-szel, ahol a JavaScriptet JSX címkékkel kevered. Mivel a JSX közelebb áll a HTML-hez, az a tendencia, hogy attribútumokat kell hozzáadni a dupla idézőjelek közé. Ezért kezdtem dupla idézőjeleket használni mindenre, csak a következetesség érdekében.

Egy dologra figyeltem fel, hogy sokkal valószínűbb, hogy egyetlen idézetet kell írnia egy angol szövegsorba, mint egy kettős idézetet („Itt vagyok”, „Ne csináld”). Tehát ezekben az esetekben a dupla idézetek kényelmesebbek lehetnek.

Kódelrendezés

A hivatalos AirBnB stílusútmutatóban van egy „nem használd, mielőtt meghatározd” szabály, amely hibát dob, ha megpróbálsz használni valamit, mielőtt meghatároznád. Ez jó szabály - különösen a változók esetében -, mert nem szabad támaszkodni az emelésre, és a let és const használatakor szem előtt kell tartania az időbeli holt zóna problémáját.

Inkább engedélyezem a függvények használatát, mielőtt meghatároznák őket. Az ok egyszerű: legtöbbször a funkciókat kisebb részfunkciókra bontja. A „no-use-before-define” szabály azonban megmondja, hogy ezeket az alfüggvényeket az eredeti függvény elé helyezze .

De az Ön alfunkciói az algoritmus elvont részei. Ne zavarjanak, amikor megnyit egy fájlt, amely a legfelső szintű funkciót tartalmazza , és amelyet a fájlon kívül használ.

Természetesen ez vitatható. De hatással van a hibakeresésre. Amikor átkódol valamilyen kód felett, és egy másik függvény hívását találja, ideális esetben képesnek kell lennie arra, hogy alatta nézzen, vagy - legrosszabb esetben - görgessen lefelé néhány alfunkciót, és megtalálja azt, amit keres.

Ez kombinálva Airbnb funkciója nyilatkozat ellen funkció kifejezéstszabály,szabadságot adhat a modulok vagy a függvénykönyvtárak tetszés szerinti felépítésére, miközben biztosíthatja, hogy véletlenül ne hívjon meg egy inicializálatlan függvényt.

Const over let

Itt van még egy kis eltérés a stílus útmutatótól. A konfigurációmban észreveheti:

"prefer-const": 1

Az Airbnb config, ez van beállítva, hogy 2, amely áll a hiba , míg 1 jelentése figyelmeztetés .

Ha nem érted, miért érdemes inkább a const helyett a let, inkább itt és itt olvashatsz róla.

Az eltérésemmel kapcsolatban inkább a figyelmeztetést részesítem előnyben, mert vannak olyan helyzetek, amikor nem egy változó hozzárendelését változtatja meg, hanem annak sok tartalmát.

Nézze meg ezt a kódot:

A szabályok megmondják, hogy ez helyes - a hash- nak const- nak kell lennie, mert nincs hozzárendelve. De ennek soha nem volt értelme számomra. Tudatában kell lennem, hogy a hash-ban nagyon sok változás történik .

Tehát a let segítségével jelzem azt a tényt, hogy a változó változhat. A const és let több jelentést kölcsönöz a változóknak, és semmilyen módon nem rejtheti el az igazságot.

Kód komplexitás

Ciklikusan kódolhatja az egyes funkciók összetettségének kiszámítását.

A bonyolultság max. Szintjéről való döntés nehéz. Ideális esetben a lehető legkisebbnek kell lennie, vagyis a funkcióinak legfeljebb 1 vagy 2 elágazási lehetőséggel kell rendelkezniük.

Van értelme, hogy ez a szám a lehető legkisebb legyen a kód újrafelhasználása és tesztelése szempontjából. De van, amikor nehezebb a funkciókat lebontani. Ezért a bonyolultságot inkább figyelmeztetésnek, mint hibának tekintem.

A legfontosabb itt az a funkciók számának korlátozása, amelyek elérik ezt a maximális bonyolultsági határt. Még egy közepes méretű kódbázisban sem szeretnék több mint 10 olyan funkciót látni, amelyek megszegik ezt a szabályt. Tehát a maximális 5 értéket választottam, hogy kiemeljem ezeket a funkciókat. Ezeket a funkciókat fogom megcélozni, amikor lesz időm néhány refaktorozásra.

A komplexitás többféleképpen is megoldható. A kisebb funkciókra való visszafogás nyilvánvaló. Egy másik lehetőség a kapcsoló utasításainak átalakítása hozzárendelési hozzárendelésekké.

Több vitát folytattunk a csapatunkban, és végül 5-öt használtunk referenciaértékként a max komplexitás szabályára. De bizonyos esetekben lemegyünk 4-re, csak azért, hogy biztosak legyünk abban, hogy tiszta és egyszerű kódot írunk.

Megjegyzés a React-ről

Mivel sokat dolgozom a React-tel, és az AirBnB konfigurációja rengeteg szabályt tartalmaz ezen a területen, itt is be akartam illeszteni néhány preferenciámat ezekre.

A React felülírásaim fő célja a szokásos JavaScript modulok és a React összetevők, valamint a JavaScript kód és a JSX közötti differenciálás korlátozása. Ezért választok hasonló behúzást és dupla idézőjeleket az összes JSX attribútumhoz. Ezért inkább az összes fájlt a .js kiterjesztéssel hagyom.

Végül az osztály vs gyári alkatrészek kapcsán inkább az utóbbiakat részesítem előnyben. Nem látok semmilyen előnyt az osztályok használatának ezen a ponton. Lehet, hogy írok egy jövőbeni bejegyzést, kitérve arra, hogy miért érzek így.

Nagyjából ennyi! Remélem tetszett olvasni ezt. Üdvözlöm az alábbi visszajelzéseket.

Ha tetszett a cikk, kattintson az alábbi zöld szívre, és tudom, hogy erőfeszítéseim nem hiábavalók.