de Daniel Simmons

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 și import 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 sau let. 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ât function 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 folosite for–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 sau Function(...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.