Nimeni nu își propune să scrie cod urât, cu un stil inconsistent. Pur și simplu se întâmplă.

Chiar ca singurul dezvoltator dintr-un proiect, cu cât trece mai mult timp și cu cât mai mult cod devii, cu atât devine mai greu să menții un stil de cod consistent.

De aceea ai nevoie de un ghid de stil.

Am experimentat din prima mână cât de mult pot realiza mai multe echipe după adoptarea unui ghid de stil.

Nu mai este nevoie să faceți mici apeluri de judecată de stil pe tot parcursul zilei. Consultați doar ghidul de stil.

Și atunci când un coechipier trebuie să vă mențină codul, acesta este un cod curat pe care îl poate citi și înțelege.

Adoptarea unui ghid de stil este unul dintre cele mai simple lucruri pe care le puteți face pentru a spori capacitatea de întreținere a codului – ceea ce crește în cele din urmă productivitatea echipei. Deci, să explorăm cel mai popular mod de a face acest lucru.

Introduceți AirBnB + ESLint

Ecosistemul JavaScript oferă o mare varietate de instrumente și ghiduri de stil. Acest lucru nu ar trebui să surprindă pe nimeni. cu JavaScript, ne-am așteptat la o mare varietate de toate.

Dar pe măsură ce ecosistemul se maturizează, dezvoltatorii experimentați încep să tânjească după „modul standard” de a face lucruri pe care ecosistemele mai solidificate îl oferă.

Sunteți binevenit bineînțeles să petreceți câteva zile explorând ecosistemul JavaScript și comparând diferite instrumente, dar voi încerca să vă economisesc ceva timp: ESLint este cel mai popular instrument de scurgere JavaScript și Ghidul de stil al AirBnB este cel mai utilizat ghid de stil.

Pentru mai multe detalii despre adăugarea ESLint la finalizarea proiectului acest link.

Odată ce ați făcut acest lucru la distanță, vă puteți configura proiectul pentru a aplica ghidul de stil al AirBnB instalând pachetul lor npm:

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

Adăugați următoarea linie în .eslintrc fişier

"extends": "airbnb"

Și voilà! Codul dvs. face acum obiectul regulilor celui mai popular ghid de stil JavaScript. Codificare fericită!

Standardele sunt supraevaluate

Deși sunt de acord cu majoritatea regulilor din ghidul de stil, iată o listă de suprascrieri pe care le-am compilat. Aceasta este ceea ce .eslintrc fișierele din folderele rădăcină ale proiectelor arată ca:

Permiteți-mi să explic în detaliu raționamentul din spatele fiecărei personalizări.

Indentare

Filele VS spațiu de război pot distruge prietenii și chiar sabota relații romantice.

Prefer să îmi indentez spațiile de cod 4, chiar dacă marea majoritate a configurațiilor de acolo preferă o indentare de 2.

Raționamentul meu este că, pentru a scrie un cod curat, indentările mai mari vă oferă o reprezentare vizuală mai bună a cât de adâncă este cuibărirea în funcțiile dvs. și câte ramuri diferite aveți.

Cu siguranță nu ar trebui să adăugați un cod mai adânc de 3 sau 4 straturi într-un fișier JavaScript (este un miros de cod). Așadar, având 4 spații vă oferă o lizibilitate mai bună, păstrând în același timp alte reguli, cum ar fi păstrarea codului dvs. într-o limită de 80 sau 120 de caractere pe linie.

De asemenea, indentarea este una dintre regulile care inspiră mai mult „aer” în ghidul de stil implicit al AirBnB. Prin urmare, codul dvs. nu se aglomerează atât de rău în partea stângă a editorului.

Spațiere

Aceasta este probabil cea mai mare abatere de la standard. Urăsc codul aglomerat. Am început să scriu cod cu spațiu suplimentar în urmă cu mai bine de 2 ani și nu m-am uitat niciodată înapoi.

Deci, ce înseamnă aceste reguli? Ei bine, aruncați o privire la următorul cod. Respectă din punct de vedere tehnic regulile ghidului oficial de stil al AirBnB.

Știu, este cam confuz. Am încercat să caut o funcție de complexitate medie dintr-una din bazele mele de coduri, dar a trebuit să o ofensez mult, așa că nu încercați să înțelegeți logica din spatele codului (pentru că nu există niciuna). Încercați doar să-l citiți. Încercați să vă concentrați, de exemplu, asupra variabilelor care sunt utilizate în mai multe locuri, când parametrii sunt trecuți către funcții și unde sunt apelurile de funcții.

Acum aruncați o privire asupra aceluiași cod, dar cu regulile de spațiere suplimentare aplicate:

Nu spun că este foarte ușor de citit acum, dar puteți identifica mai ușor unde aveți parametrii trimiși la funcții – în special în jurul funcțiilor curri.

Verificați, de asemenea, diferența dintre indentarea spațiului 2 și 4 în cele două exemple.

La început, aceste tehnici s-ar putea să nu pară o mare îmbunătățire. Vă încurajez să le încercați. Cred că veți experimenta rapid ce diferență face acest lucru.

Citate războaie

În timp ce primele două categorii au avut câteva argumente clare, trebuie să spun că singur vs. dubla decizia citatelor este una foarte subiectivă.

Preferința mea pentru ghilimele duble provine probabil din lucrul foarte mult cu React, unde amestecați JavaScript cu Etichete JSX. Deoarece JSX este mai aproape de HTML, tendința este de a adăuga atribute între ghilimele duble. Așa că am început să folosesc ghilimele duble pentru orice, doar pentru consistență.

Un lucru pe care l-am observat este că este mult mai probabil să aveți nevoie să scrieți un singur citat într-un șir de text în engleză decât un citat dublu („Sunt aici”, „Nu faceți asta”). Deci, ghilimelele duble ar putea fi mai convenabile în aceste cazuri.

Aranjament cod

Ghidul oficial de stil AirBnB are o regulă „no-use-before-define”, care aruncă o eroare dacă încercați să utilizați ceva înainte de al defini. Aceasta este o regulă bună – mai ales pentru variabile – deoarece nu trebuie să vă bazați pe ridicare și ar trebui să păstrați zona moartă temporală problemă în minte atunci când utilizați let și const.

Prefer să permit funcțiile să fie utilizate înainte de a fi definite. Motivul este simplu: de cele mai multe ori, vă veți descompune funcțiile în sub-funcții mai mici. Cu toate acestea, regula „no-use-before-define” vă va spune să puneți aceste funcții secundare inainte de funcția originală.

Dar sub-funcțiile dvs. sunt acolo pentru a abstractiza părți ale algoritmului. Nu ar trebui să vă deranjeze atunci când deschideți un fișier care conține funcție de nivel superior, pe care îl utilizați în afara fișierului.

Desigur, acest lucru este discutabil. Dar are impact asupra depanării. Când repetați un anumit cod și găsiți un apel către o altă funcție, în mod ideal ar trebui să puteți privi dedesubt sau, în cel mai rău caz, să derulați câteva funcții secundare și să găsiți ceea ce căutați.

Aceasta, în combinație cu AirBnB’s funcţie declaraţie împotriva funcției expresie regulă, vă poate oferi libertatea de a vă structura modulele sau bibliotecile de funcții după cum doriți, asigurându-vă în același timp că nu apelați accidental o funcție neinițială.

Const over let

Iată o altă mică abatere de la ghidul de stil. Puteți observa în configurația mea:

"prefer-const": 1

În configurația AirBnB, aceasta este setată la 2, care înseamnă eroare, in timp ce 1 înseamnă avertizare.

Acum, dacă nu înțelegeți de ce ar trebui să preferați const în loc să lăsați, puteți citi mai multe despre asta aici și aici.

În ceea ce privește abaterea mea, prefer un avertisment, deoarece există situații în care nu schimbați atribuirea unei variabile, dar schimbați mult conținutul acesteia.

Aruncați o privire la acest cod:

Regulile vă vor spune că este corect – hash ar trebui să fie const deoarece nu este reatribuit. Dar acest lucru nu a avut niciodată sens pentru mine. Ar trebui să știu că în interior se întâmplă o mare schimbare hash.

Așa că voi folosi lăsa pentru a semnaliza faptul că variabila poate fi modificată. const și lăsa ar trebui să acorde mai mult sens variabilelor dvs. și nu ar trebui să ascundă adevărul în niciun fel.

Complexitatea codului

Poti complexitatea codului ciclomatic pentru a calcula complexitatea fiecărei funcții.

Decizia asupra unui nivel maxim de complexitate este dificilă. În mod ideal ar trebui să fie cât mai redus posibil, ceea ce înseamnă că funcțiile dvs. ar trebui să aibă cel mult 1 sau 2 posibilități de ramificare.

Este logic să aveți acel număr cât mai mic posibil din perspectiva refolosirii și testării codului. Dar există momente în care este mai greu să descompunem funcțiile. De aceea, văd complexitatea mai mult ca un avertisment decât ca o eroare.

Important este aici să limitezi numărul de funcții care ating această limită maximă de complexitate. Chiar și într-o bază de cod de dimensiuni medii, nu aș vrea să văd mai mult de 10 funcții care încalcă această regulă. Așa că am ales valoarea maximă de 5, pentru a evidenția acele funcții. Voi viza aceste funcții când voi avea timp să fac o refacere.

Complexitatea poate fi rezolvată în mai multe moduri. Refactorizarea în funcții mai mici este una evidentă. O altă opțiune este transformarea dvs. intrerupator declarații în sarcini de cartografiere.

Am avut mai multe dezbateri în interiorul echipei noastre și am ajuns să folosim 5 ca valoare de referință pentru regula de complexitate maximă. Dar, în unele cazuri, coborâm la 4, doar pentru a fi siguri că scriem un cod simplu și curat.

O notă despre React

Deoarece lucrez mult cu React, iar configurația AirBnB conține, de asemenea, un număr mare de reguli în acea zonă, am vrut să includ aici și câteva dintre preferințele mele.

Scopul principal al modificărilor mele React este de a limita diferențierea dintre modulele JavaScript obișnuite și componentele React, precum și între codul JavaScript și JSX. De aceea aleg o indentare similară și utilizarea ghilimelelor duble pentru toate atributele JSX. Și de aceea prefer să las toate fișierele mele cu extensia .js.

În cele din urmă, legat de componente de clasă vs fabrică, Tind să-l prefer pe acesta din urmă. Nu văd niciun avantaj în utilizarea acestui curs în acest moment. S-ar putea să scriu o viitoare postare despre ce mă simt așa.

Cam atât! Sper că ți-a plăcut să citești asta. Salut feedback-ul dvs. mai jos.

Dacă ți-a plăcut articolul, dă clic pe inima verde de mai jos și voi ști că eforturile mele nu sunt în zadar.