nimic nu este pus în piatră aici. Acestea sunt preferințe de stil, nu dogme religioase.

if (condition) { // do this // ...and that // ...and that}

o construcție cu o singură linie, cum ar fi if (condition) doSomething(), este un caz important de margine. Ar trebui să folosim bretele deloc?

iată variantele adnotate astfel încât să le puteți judeca lizibilitatea pentru dvs.:

pentru un cod foarte scurt, este permisă o linie, de ex.if (cond) return null. Dar un bloc de cod (ultima variantă) este de obicei mai lizibil.

lungimea liniei

nimănui nu-i place să citească o linie orizontală lungă de cod. Este cea mai bună practică să le împărțiți.

de exemplu:

// backtick quotes ` allow to split the string into multiple lineslet str = ` ECMA International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.`;

și, pentruif :

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

lungimea maximă a liniei trebuie convenită la nivel de echipă. De obicei sunt 80 sau 120 de caractere.

liniuțe

există două tipuri de liniuțe:

• liniuțe orizontale: 2 sau 4 spații.

  o indentare orizontală se face folosind fie 2 sau 4 spații sau simbolul tab orizontal (fila cheie). Care dintre ele să aleagă este un vechi război sfânt. Spațiile sunt mai frecvente în zilele noastre.

  un avantaj al spațiilor față de File este că spațiile permit configurații mai flexibile de liniuțe decât simbolul tab.

  de exemplu, putem alinia parametrii cu bracketul de deschidere, astfel:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• liniuțe verticale: linii goale pentru împărțirea codului în blocuri logice.

  chiar și o singură funcție poate fi adesea împărțită în blocuri logice. În exemplul de mai jos, inițializarea variabilelor, bucla principală și returnarea rezultatului sunt împărțite vertical:

  function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}

  introduceți o nouă linie suplimentară în care ajută la citirea codului. Nu ar trebui să existe mai mult de nouă linii de cod fără o indentare verticală.

punct și virgulă

un punct și virgulă ar trebui să fie prezent după fiecare afirmație, chiar dacă ar putea fi omisă.

există limbi în care un punct și virgulă este cu adevărat opțional și este rar folosit. În JavaScript, totuși, există cazuri în care o pauză de linie nu este interpretată ca punct și virgulă, lăsând codul vulnerabil la erori. Vedeți mai multe despre asta în capitolul structura codului.

Dacă sunteți un programator JavaScript experimentat, puteți alege un stil de cod fără punct și virgulă, cum ar fi StandardJS. În caz contrar, este mai bine să utilizați punct și virgulă pentru a evita posibilele capcane. Majoritatea dezvoltatorilor au pus punct și virgulă.

niveluri de cuibărit

încercați să evitați codul de cuibărit prea multe niveluri adânci.

de exemplu, în buclă, uneori este o idee bună să folosiți Directivacontinue pentru a evita cuibărirea suplimentară.

de exemplu, în loc de a adăuga un imbricat if condiționată ca aceasta:

for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

putem scrie:

for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

Un lucru similar se poate face cuif/elseșireturn.

de exemplu, două construcții de mai jos sunt identice.

opțiunea 1:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); } else { let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result; }}

Opțiunea 2:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); return; } let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result;}

al doilea este mai ușor de citit, deoarece „cazul special” al n < 0este tratat din timp. Odată ce verificarea este făcută, putem trece la fluxul de cod” principal ” fără a fi nevoie de cuiburi suplimentare.

plasarea funcțiilor

dacă scrieți Mai multe funcții „helper” și codul care le utilizează, există trei moduri de organizare a funcțiilor.

de cele mai multe ori, este preferată a doua variantă.

asta pentru că atunci când citim codul, vrem mai întâi să știm ce face. Dacă codul merge mai întâi, atunci devine clar de la început. Apoi, poate că nu va trebui să citim deloc funcțiile, mai ales dacă numele lor sunt descriptive pentru ceea ce fac de fapt.

ghiduri de stil

Un ghid de stil conține reguli generale despre codul „cum se scrie”, de ex.ce citate să folosești, câte spații să indentezi, lungimea maximă a liniei etc. O mulțime de lucruri minore.

când toți membrii unei echipe folosesc același ghid de stil, codul arată uniform, indiferent de membrul echipei care l-a scris.desigur ,o echipă își poate scrie întotdeauna propriul ghid de stil, dar de obicei nu este nevoie. Există multe ghiduri existente din care să alegeți.

câteva alegeri populare:

• Google JavaScript Style Guide
• Airbnb JavaScript Style Guide
• Idiomatic.JS
• StandardJS
• (plus multe altele)

Dacă sunteți un dezvoltator novice, începeți cu foaia de înșelăciune la începutul acestui capitol. Apoi, puteți răsfoi alte ghiduri de stil pentru a ridica mai multe idei și pentru a decide care dintre ele vă place cel mai mult.

Linters automate

Linters sunt instrumente care pot verifica automat stilul codului dvs. și pot face sugestii de îmbunătățire.

mare lucru despre ei este că stil de verificare pot găsi, de asemenea, unele bug-uri, cum ar fi greșeli de tipar în nume de variabile sau funcții. Datorită acestei caracteristici, se recomandă utilizarea unui linter chiar dacă nu doriți să respectați un anumit „stil de cod”.

iată câteva instrumente bine-cunoscute linting:

• JSLint – una dintre primele linters.
• JSHint – mai multe setări decât JSLint.
• ESLint-probabil cel mai nou.

toate acestea pot face treaba. Autorul folosește ESLint.

cele mai multe linters sunt integrate cu mulți editori populare: doar activați pluginul în editor și configurați stilul.

de exemplu, pentru ESLint ar trebui să faceți următoarele:

1. Install Node.js.
2. instalați ESLint cu comandanpm install -g eslint (npm este un instalator de pachete JavaScript).
3. creați un fișier de configurare numit.eslintrc în rădăcina proiectului JavaScript (în folderul care conține toate fișierele dvs.).
4. instalați / activați pluginul pentru editorul dvs. care se integrează cu ESLint. Majoritatea editorilor au unul.

Iată un exemplu de .eslintrc fișier:

{ "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}

aici Directiva"extends" indică faptul că configurația se bazează pe setul de setări „eslint:recomandat”. După aceea, specificăm propria noastră.

De asemenea, este posibil să descărcați seturi de reguli de stil de pe web și să le extindeți în schimb. Consultați http://eslint.org/docs/user-guide/getting-started pentru mai multe detalii despre instalare.

de asemenea, anumite IDE-uri au linting încorporat, care este convenabil, dar nu la fel de personalizabil ca ESLint.

rezumat

toate regulile de sintaxă descrise în acest capitol (și în ghidurile de stil la care se face referire) au ca scop creșterea lizibilității codului. Toate acestea sunt discutabile.

când ne gândim să scriem un cod „mai bun”, întrebările pe care ar trebui să ni le punem sunt: „ce face Codul mai lizibil și mai ușor de înțeles?”și” ce ne poate ajuta să evităm Erorile?”Acestea sunt principalele lucruri de care trebuie să țineți cont atunci când alegeți și dezbateți stilurile de cod.

citirea ghidurilor de stil populare vă va permite să fiți la curent cu cele mai recente idei despre tendințele stilului de cod și cele mai bune practici.