Õhu hingamine AirBnB JavaScripti stiilijuhendisse

Keegi ei kavatse kirjutada koledat, ebajärjekindla stiiliga koodi. See lihtsalt juhtub.

Isegi kui projekti ainus arendaja on, siis mida rohkem aega möödub ja mida rohkem koodi väntate, seda raskem on järjepideva koodistiili säilitamine.

Sellepärast vajate stiilijuhendit.

Olen omal nahal kogenud, kui palju meeskondi saab pärast stiilijuhendi vastuvõtmist saavutada.

Teil pole enam vaja kogu päeva jooksul stiilis hinnanguid teha. Vaadake lihtsalt stiilijuhendit.

Ja kui meeskonnakaaslane peab teie koodi säilitama, on see puhas kood, mida nad saavad lugeda ja mõista.

Stiilijuhendi vastuvõtmine on üks lihtsamaid asju, mida saate oma koodi hooldatavuse parandamiseks teha - mis suurendab lõppkokkuvõttes teie meeskonna tootlikkust. Nii et uurime kõige populaarsemat viisi seda teha.

Sisestage AirBnB + ESLint

JavaScripti ökosüsteem pakub mitmesuguseid tööriistu ja stiilijuhiseid. See ei tohiks kedagi üllatada. JavaScripti abil oleme oodanud mitmesugust kõike.

Kuid kui ökosüsteem küpseb, hakkavad kogenud arendajad igatsema "tavapärase viisi" järele, kuidas teha asju, mida tahkestunud ökosüsteemid pakuvad.

Muidugi olete teretulnud veetma paar päeva JavaScripti ökosüsteemi uurimisel ja erinevate tööriistade võrdlemisel, kuid proovin säästa teie aega : ESLint on kõige populaarsem JavaScripti kiintööriist ja AirBnB stiilijuhend on kõige laialdasemalt kasutatav stiilijuhend.

Lisateavet ESLinti lisamise kohta projekti kassasse leiate sellest lingist.

Kui olete selle ruudu ära hoidnud, saate oma projekti konfigureerida AirBnB stiilijuhi jõustamiseks, installides nende paketi npm:

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

Lisage oma .eslintrc- faili järgmine rida

"extends": "airbnb"

Ja voilà! Teie koodi suhtes kehtivad nüüd kõige populaarsema JavaScripti stiilijuhendi reeglid. Head kodeerimist!

Standardid on üle hinnatud

Olen nõus enamiku stiilijuhi reeglitega, kuid siin on minu koostatud ülekirjutuste loend. Nii näevad projektide juurkaustades olevad .eslintrc- failid välja:

Lubage mul üksikasjalikult selgitada kõigi nende kohanduste tagamaid.

Taane

Vahekaardid VS space sõda võivad potentsiaalselt rikkuda sõprussuhteid ja võib-olla isegi romantilisi suhteid saboteerida.

Ma eelistan taandada oma kood 4 tühikuid, kuigi valdav enamus sealseid konfigureerijaid eelistab taanet 2.

Minu arutluskäik on see, et puhta koodi kirjutamiseks annavad suuremad taanded parema visuaalse ülevaate sellest, kui sügav on teie funktsioonides pesitsemine ja kui palju teil on erinevaid harusid.

Kindlasti ei tohiks pesitseda JavaScripti faili sisse sügavam kui 3 või 4 kihti kood (see on koodilõhn). Nii et 4 tühiku olemasolu pakub paremat loetavust, säilitades samas muud reeglid, näiteks koodi hoidmine reale 80 või 120 tähemärgi kohta.

Samuti on taane üks reegleid, mis õhutab AirBnB vaikimisi stiilijuhendisse rohkem õhku. Seetõttu ei tungi teie kood redaktori vasakul küljel nii hullult.

Vahed

See on ilmselt suurim kõrvalekalle standardist. Ma vihkan ülerahvastatud koodi. Hakkasin lisaruumi sisestusega koodi kirjutama rohkem kui 2 aastat tagasi ja ma ei vaadanud kunagi tagasi.

Mida need reeglid siis tähendavad? Vaadake järgmist koodi. See järgib tehniliselt AirBnB ametliku stiilijuhendi reegleid.

Ma tean, see on natuke segane. Proovisin ühest oma koodibaasist otsida keskmise keerukusega funktsiooni, kuid pidin seda palju hägustama, nii et ärge proovige aru saada koodi taga olevast loogikast (kuna seda pole). Lihtsalt proovige seda lugeda. Proovige keskenduda näiteks muutujatele, mida kasutatakse mitmes kohas, kui parameetrid edastatakse funktsioonidele ja kus on funktsioonide väljakutsed.

Nüüd vaadake sama koodi, kuid rakendades täiendavaid tühikute reegleid:

Ma ei ütle, et see oleks nüüd hästi loetav, kuid saate hõlpsamini tuvastada, kuhu olete funktsioonidele parameetrid saadetud - eriti karritud funktsioonide ümber.

Samuti kontrollige kahe näite erinevust 2- ja 4-tühise taande vahel.

Esialgu ei pruugi need võtted tunduda suure edusammuna. Soovitan teil proovida. Ma arvan, et kogete kiiresti, mis vahet sellel on.

Tsiteeri sõdu

Kuigi kahel esimesel kategoorial olid mõned selged argumendid, pean ütlema, et üksikute ja topeltpakkumistega otsus on väga subjektiivne.

Minu eelistus topelt jutumärkidele tuleneb ilmselt palju töötamisest Reactiga, kus segate JavaScripti JSX-i siltidega. Kuna JSX on HTML-ile lähemal, on kalduvus atribuute lisada topelt jutumärkide vahele. Nii et hakkasin kõiges topelt jutumärke kasutama, lihtsalt järjekindluse tagamiseks.

Üks asi, mida olen märganud, on see, et teil on palju tõenäolisem, et peate kirjutama ühe tsitaadi ingliskeelse tekstirea sisse kui topeltpakkumise (“I'm here”, “Don't do that”). Nii et topelt jutumärgid võivad nendel juhtudel olla mugavamad.

Koodide paigutus

Ametlikul AirBnB-stiili juhendil on reegel "enne kasutamist ei tohi määratleda", mis viskab vea, kui proovite midagi enne selle määratlemist kasutada. See on hea reegel - eriti muutujate puhul - kuna te ei tohiks lootma heiskamisele ja let ja const kasutamisel peaksite silmas pidama ajalise surnud tsooni probleemi.

Eelistan lubada funktsioonide kasutamist enne nende määratlemist. Põhjus on lihtne: enamasti jagate oma funktsioonid väiksemateks alafunktsioonideks. Reegel „enne kasutamist ei tohi määratleda“ käsib teil need alafunktsioonid panna enne algset funktsiooni.

Kuid teie alafunktsioonid on algoritmi abstraktsete osade jaoks. Need ei tohiks teid häirida, kui avate faili, mis sisaldab teie ülemise taseme funktsiooni , mida kasutate väljaspool faili.

Muidugi on see vaieldav. Kuid see mõjutab silumist. Kui kordate mõnda koodi ja leiate kõne mõnele teisele funktsioonile, peaksite ideaalis saama selle alla vaadata või - halvimal juhul - kerida läbi mõne alafunktsiooni ja leida see, mida otsite.

See, koos airbnb funktsiooni deklaratsiooni vastu funktsiooni väljendusreegel,võib anda teile vabaduse mooduleid või funktsioonide teeke oma äranägemise järgi struktureerida, tagades samas, et te ei nimetaks kogemata initsialiseerimata funktsiooni.

Const üle lasta

Siin on veel üks väike kõrvalekalle stiilijuhendist. Minu konfiguratsioonis võite märgata:

"prefer-const": 1

AirBnB seadistuses on see seatud väärtusele 2, mis tähistab viga , samas kui üks tähistab hoiatust .

Kui te ei saa aru, miks peaksite eelistama const-i letile, saate selle kohta lugeda siit ja siit.

Minu kõrvalekaldumise osas eelistan hoiatust, sest on olukordi, kus te ei muuda muutuja omistamist, vaid palju selle sisu.

Vaadake seda koodi:

Reeglid ütlevad teile, et see on õige - räsi peaks olema const, kuna seda ei määrata uuesti. Kuid see ei olnud minu jaoks kunagi mõistlik. Ma peaksin teadma, et räsi sees toimub palju muutusi .

Nii et ma kasutan let, et anda märku asjaolust, et muutuja võib muutuda. const ja let peaksid teie muutujatele rohkem tähendust andma ega tohiks mingil viisil tõde varjata.

Koodi keerukus

Iga funktsiooni keerukuse arvutamiseks võite kasutada tsüklomaatilist koodi keerukust.

Maksimaalse keerukustaseme üle otsustamine on keeruline. Ideaalis peaks see olema võimalikult madal, see tähendab, et teie funktsioonidel peaks olema maksimaalselt 1 või 2 hargnemisvõimalust.

Koodide taaskasutuse ja testimise seisukohalt on mõistlik, et see number oleks võimalikult väike. Kuid on olukordi, kus on raskem funktsioone lagundada. Seetõttu näen keerukust pigem hoiatusena kui siis veana.

Siinkohal on oluline piirata maksimaalse keerukuse piirini jõudvate funktsioonide arvu. Isegi keskmise suurusega koodibaasis ei tahaks ma näha rohkem kui 10 funktsiooni, mis seda reeglit rikuvad. Nii et valisin nende funktsioonide esiletõstmiseks maksimaalse väärtuse 5. Sihin need funktsioonid siis, kui mul on aega veidi ümber teha.

Keerukust saab lahendada mitmel viisil. Ümberkujundamine väiksematesse funktsioonidesse on ilmne. Teine võimalus on muuta oma lüliti avaldused kaardistamise ülesandeid.

Meil oli oma meeskonnas mitu arutelu ja lõpuks kasutasime 5 maksimaalse keerukuse reegli võrdlusväärtusena. Kuid mõnel juhul langeme 4-ni, et olla kindel, et kirjutame puhta ja lihtsa koodi.

Märkus React

Kuna töötan palju Reactiga ja ka AirBnB konfiguratsioon sisaldab selles piirkonnas kopsakat arvu reegleid, tahtsin ka siia lisada mõned oma eelistused nendele.

Minu Reacti alistamiste peamine eesmärk on piirata tavaliste JavaScripti moodulite ja React'i komponentide ning JavaScripti koodi ja JSX-i eristamist. Seetõttu valin kõigi JSX-atribuutide jaoks sarnase taande ja topelt jutumärkide kasutamise. Ja seepärast eelistan jätta kõik oma failid laiendiga .js.

Lõpuks, seoses klassi vs tehase komponentidega, kipun eelistama viimaseid. Ma ei näe klasside kasutamisel sel hetkel mingit eelist. Võin kirjutada tulevase postituse, laiendades seda, miks ma nii tunnen.

Umbes nii! Loodan, et teile meeldis seda lugeda. Tervitan teie tagasisidet allpool.

Kui teile artikkel meeldis, klõpsake alloleval rohelisel südamel ja ma tean, et minu jõupingutused pole asjata.