de Daniel Simmons
Conţinut
- 1 13 puncte de remarcat din Ghidul de stil JavaScript de la Google
- 1.0.0.1 Folosiți spații, nu file
- 1.0.0.2 Punctele și virgulele sunt obligatorii
- 1.0.0.3 Nu utilizați module ES6 (încă)
- 1.0.0.4 Alinierea orizontală este descurajată (dar nu este interzisă)
- 1.0.0.5 Nu mai folosiți var
- 1.0.0.6 Funcțiile săgeți sunt preferate
- 1.0.0.7 Utilizați șiruri de șabloane în loc de concatenare
- 1.0.0.8 Nu utilizați continuări de linie pentru corzi lungi
- 1.0.0.9 „Pentru … din” este tipul preferat de „pentru buclă”
- 1.0.0.10 Nu folosi eval ()
- 1.0.0.11 Constantele trebuie denumite în ALL_UPPERCASE separate prin sublinieri
- 1.0.0.12 O variabilă pe declarație
- 1.0.0.13 Folosiți ghilimele simple, nu ghilimele duble
- 1.0.0.14 O notă finală
13 puncte de remarcat din Ghidul de stil JavaScript de la Google
Pentru oricine care nu este deja familiarizat cu aceasta, Google scoate un ghid de stil pentru scrierea JavaScript care stabilește (ceea ce Google crede a fi) cele mai bune practici stilistice pentru scrierea unui cod curat și ușor de înțeles.
Acestea nu sunt reguli dure și rapide pentru scrierea unui JavaScript valid, ci doar interziceri pentru menținerea unor opțiuni de stil consistente și atrăgătoare în fișierele sursă. Acest lucru este deosebit de interesant pentru JavaScript, care este un limbaj flexibil și iertător, care permite o mare varietate de alegeri stilistice.
Google și Airbnb au două dintre cele mai populare ghiduri de stil. Vă recomand cu siguranță să le verificați pe amândouă dacă petreceți mult timp scriind JS.
Următoarele sunt treisprezece dintre ceea ce cred că sunt cele mai interesante și relevante reguli din Ghidul de stil JS de la Google.
Se ocupă de toate, de la probleme extrem de contestate (file versus spații și problema controversată a modului în care ar trebui să fie folosite punctele și virgulele), până la câteva specificații mai obscure care m-au surprins. Cu siguranță vor schimba modul în care îmi scriu JS-ul în continuare.
Pentru fiecare regulă, voi oferi un rezumat al specificației, urmat de un citat de susținere din ghidul de stil care descrie regula în detaliu. Dacă este cazul, voi oferi, de asemenea, un exemplu de stil în practică și îl voi contrasta cu codul care nu respectă regula.
Folosiți spații, nu file
În afară de secvența terminatorului de linie, caracterul de spațiu orizontal ASCII (0x20) este singurul caracter de spațiu alb care apare oriunde într-un fișier sursă. Aceasta implică faptul că … caracterele filelor sunt nu folosit pentru indentare.
Ghidul specifică ulterior că ar trebui să utilizați două spații (nu patru) pentru indentare.
// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}
Punctele și virgulele sunt obligatorii
Fiecare declarație trebuie terminată cu punct și virgulă. Bazarea pe inserarea automată de punct și virgulă este interzisă.
Deși nu-mi pot imagina de ce cineva se opune acestei idei, utilizarea consecventă a punctelor și virgulelor în JS devine noua dezbatere „spații versus file”. Google iese ferm aici în apărarea punctului și virgulei.
// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father="vader")
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father="vader";});
Nu utilizați module ES6 (încă)
Nu utilizați încă module ES6 (adică
export
șiimport
cuvinte cheie), deoarece semantica lor nu este încă finalizată. Rețineți că această politică va fi revizuită odată ce semantica va fi pe deplin standard.
// Don't do this kind of thing yet:
//------ lib.js ------export function square(x) { return x * x;}export function diag(x, y) { return sqrt(square(x) + square(y));}//------ main.js ------import { square, diag } from 'lib';
Alinierea orizontală este descurajată (dar nu este interzisă)
Această practică este permisă, dar este în general descurajat de la Google Style. Nici măcar nu este necesar menţine alinierea orizontală în locurile în care a fost deja utilizată.
Alinierea orizontală este practica adăugării unui număr variabil de spații suplimentare în codul dvs., pentru a face ca anumite jetoane să apară direct sub anumite alte jetoane pe liniile anterioare.
// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};
Nu mai folosiți var
Declarați toate variabilele locale cu oricare
const
saulet
. Utilizați const în mod implicit, cu excepția cazului în care o variabilă trebuie reatribuită.var
cuvântul cheie nu trebuie utilizat.
Încă văd oameni folosind var
în mostre de cod pe StackOverflow și în alte părți. Nu-mi pot da seama dacă există oameni acolo care să-i susțină cazul sau dacă este doar un caz de obiceiuri vechi moarte din greu.
// badvar example = 42;
// goodlet example = 42;
Funcțiile săgeți sunt preferate
Funcțiile săgeată oferă o sintaxă concisă și rezolvă o serie de dificultăți cu
this
. Preferați funcțiile săgeată decâtfunction
cuvânt cheie, în special pentru funcțiile imbricate
Voi fi sincer, am crezut doar că funcțiile săgeată erau grozave, deoarece erau mai concise și mai plăcute de privit. Se pare că au și un scop destul de important.
// bad[1, 2, 3].map(function (x) { const y = x + 1; return x * y;});// good[1, 2, 3].map((x) => { const y = x + 1; return x * y;});
Utilizați șiruri de șabloane în loc de concatenare
Utilizați șiruri șablon (delimitate cu
`
) peste concatenarea șirurilor complexe, mai ales dacă sunt implicate mai multe litere de șiruri. Șirurile șablon pot cuprinde mai multe linii.
// badfunction sayHi(name) { return 'How are you, ' + name + '?';}// badfunction sayHi(name) { return ['How are you, ', name, '?'].join();}// badfunction sayHi(name) { return `How are you, ${ name }?`;}// goodfunction sayHi(name) { return `How are you, ${name}?`;}
Nu utilizați continuări de linie pentru corzi lungi
Nu folosi continuări de linie (adică încheierea unei linii în interiorul unui șir literal cu o bară inversă) fie în litere obișnuite, fie în șabloane. Chiar dacă ES5 permite acest lucru, poate duce la erori complicate dacă un spațiu alb urmează după linie și este mai puțin evident pentru cititori.
Interesant este că aceasta este o regulă în care Google și Airbnb nu sunt de acord (aici este Specificațiile Airbnb).
În timp ce Google recomandă concatenarea șirurilor mai lungi (așa cum se arată mai jos), ghidul de stil al Airbnb recomandă în esență să nu faceți nimic și să permiteți șirurilor lungi să continue cât timp au nevoie.
// bad (sorry, this doesn't show up well on mobile)const longString = 'This is a very long string that far exceeds the 80 column limit. It unfortunately contains long stretches of spaces due to how the continued lines are indented.';
// goodconst longString = 'This is a very long string that ' + 'far exceeds the 80 column limit. It does not contain ' + 'long stretches of spaces since the concatenated ' + 'strings are cleaner.';
„Pentru … din” este tipul preferat de „pentru buclă”
Cu ES6, limba are acum trei tipuri diferite de
for
bucle. Totuși, toate pot fi folositefor
–of
buclele ar trebui preferate atunci când este posibil.
Acesta este unul ciudat dacă mă întrebați, dar m-am gândit să îl includ pentru că este destul de interesant că Google declară un tip preferat de for
buclă.
Am avut întotdeauna impresia că for... in
buclele erau mai bune pentru obiecte, în timp ce for... of
erau mai potrivite pentru matrice. Un „instrument potrivit pentru locul de muncă potrivit” situație de tip.
Deși specificațiile Google de aici nu contrazic neapărat această idee, este totuși interesant să știm că au o preferință în special pentru această buclă.
Nu folosi eval ()
Nu folosi
eval
sauFunction(...string)
constructor (cu excepția încărcătoarelor de cod). Aceste caracteristici sunt potențial periculoase și pur și simplu nu funcționează în medii CSP.
Pagina MDN pentru eval()
are chiar și o secțiune numită „Nu folosi eval!”
// badlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"eval( 'var result = obj.' + propName );
// goodlet obj = { a: 20, b: 30 };let propName = getPropName(); // returns "a" or "b"let result = obj[ propName ]; // obj[ "a" ] is the same as obj.a
Constantele trebuie denumite în ALL_UPPERCASE separate prin sublinieri
Se folosesc nume constante
CONSTANT_CASE
: toate literele majuscule, cu cuvinte separate prin subliniere.
Dacă sunteți absolut sigur că o variabilă nu ar trebui să se schimbe, puteți indica acest lucru scriind cu majuscule numele constantei. Acest lucru face ca imuabilitatea constantei să fie evidentă pe măsură ce se folosește în întregul cod.
O excepție notabilă de la această regulă este dacă constanta este funcțională. În acest caz, ar trebui să fie scris în camelCase.
// badconst number = 5;
// goodconst NUMBER = 5;
O variabilă pe declarație
Fiecare declarație de variabilă locală declară o singură variabilă: declarații precum
let a = 1, b = 2;
nu sunt folosite.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;
Folosiți ghilimele simple, nu ghilimele duble
Literalele șirului obișnuit sunt delimitate cu ghilimele simple
'
), mai degrabă decât ghilimele duble ("
).
Sfat: dacă un șir conține un singur caracter de ghilimel, luați în considerare utilizarea unui șablon șablon pentru a evita să scăpați de ghilimel.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ainu0027t so.';
// goodlet directive="No identification of self or mission.";
// goodlet saying = `Say it ain't so`;
O notă finală
După cum am spus la început, acestea nu sunt mandate. Google este doar unul dintre mulți giganți tehnologici, iar acestea sunt doar recomandări.
Acestea fiind spuse, este interesant să ne uităm la recomandările de stil prezentate de o companie precum Google, care angajează o mulțime de oameni geniali, care petrec mult timp scriind coduri excelente.
Puteți respecta aceste reguli dacă doriți să urmați instrucțiunile pentru „codul sursă compatibil Google” – dar, desigur, o mulțime de oameni nu sunt de acord și sunteți liber să eliminați toate acestea.
Personal, cred că există o mulțime de cazuri în care specificațiile Airbnb sunt mai atrăgătoare decât cele ale Google. Indiferent de poziția pe care o luați cu privire la aceste reguli speciale, este încă important să aveți în vedere consistența stilistică atunci când scrieți orice fel de cod.
#puncte #remarcat #din #ghidul #stil #JavaScript #Google
13 puncte de remarcat din ghidul de stil JavaScript de la Google