13 vrijednih pažnje iz Googleovog vodiča za stil JavaScript-a

Za sve one koji ga već nisu upoznali, Google izdaje stilski vodič za pisanje JavaScript-a koji iznosi (ono što Google vjeruje da jest) najbolje stilske prakse za pisanje čistog, razumljivog koda.

Ovo nisu stroga pravila za pisanje valjanog JavaScript-a, već samo propisi za održavanje dosljednih i privlačnih izbora stilova u svim izvornim datotekama. Ovo je posebno zanimljivo za JavaScript, koji je fleksibilan jezik koji oprašta i omogućuje široku paletu stilskih izbora.

Google i Airbnb imaju dva najpopularnija vodiča za stil. Svakako bih vam preporučio da ih provjerite ako provodite puno vremena pišući JS.

Slijedi trinaest najzanimljivijih i najrelevantnijih pravila iz Googleova vodiča za stil JS-a.

Oni se bave svime, od žestoko osporavanih pitanja (kartice nasuprot razmacima i kontroverzno pitanje kako se zarez koriste), do još nekoliko nejasnih specifikacija koje su me iznenadile. Oni će definitivno promijeniti način na koji pišem svoj JS u budućnosti.

Za svako pravilo dat ću sažetak specifikacije, nakon čega slijedi popratni citat iz stilskog vodiča koji detaljno opisuje pravilo. Gdje je primjenjivo, pružit ću i primjer stila u praksi, te ga uporediti s kodom koji ne slijedi pravilo.

Koristite razmake, a ne kartice

Osim završetka linije, ASCII vodoravni razmak (0x20) jedini je razmak koji se pojavljuje bilo gdje u izvornoj datoteci. To podrazumijeva da ... Znakovi kartice ne koriste se za uvlačenje.

Vodič kasnije navodi da za uvlačenje trebate koristiti dva razmaka (a ne četiri).

// badfunction foo() {∙∙∙∙let name;}// badfunction bar() {∙let name;}// goodfunction baz() {∙∙let name;}

Potrebni su zarez i zarez

Svaka se izjava mora završiti zarezom i zarezom. Oslanjanje na automatsko umetanje zarezom zabranjeno je.

Iako ne mogu zamisliti zašto se itko protivi ovoj ideji, dosljedna upotreba zareza u JS-u postaje nova rasprava 'razmaci nasuprot tabulatorima'. Google ovdje čvrsto izlazi u obranu točke i zareza.

// badlet luke = {}let leia = {}[luke, leia].forEach(jedi => jedi.father = 'vader')
// goodlet luke = {};let leia = {};[luke, leia].forEach((jedi) => { jedi.father = 'vader';});

Nemojte koristiti ES6 module (još)

Još nemojte koristiti ES6 module (tj. exportI importključne riječi), jer njihova semantika još nije finalizirana. Imajte na umu da će se ovo pravilo ponovno pregledati kada semantika bude potpuno standardna.
// 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';

Ne preporučuje se vodoravno poravnanje (ali nije zabranjeno)

Ova je praksa dopuštena, ali je Google Style općenito obeshrabruje . Nije čak potrebno održavati vodoravno poravnanje na mjestima gdje je već bilo korišteno.

Horizontalno poravnanje praksa je dodavanja promjenjivog broja dodatnih razmaka u kodu kako bi se određeni tokeni pojavili izravno ispod određenih drugih tokena u prethodnim redovima.

// bad{ tiny: 42, longer: 435, };
// good{ tiny: 42, longer: 435,};

Ne koristite više var

Deklarirajte sve lokalne varijable s bilo constili let. Koristite const prema zadanim postavkama, osim ako varijablu treba ponovno dodijeliti. varSe ne smije koristiti ključne riječi.

Još uvijek vidim ljude koji koriste varuzorke koda na StackOverflowu i drugdje. Ne mogu znati postoje li vani ljudi koji će to dokazati ili je to slučaj samo starih navika koje teško umiru.

// badvar example = 42;
// goodlet example = 42;

Poželjne su funkcije strelica

Funkcije strelica pružaju sažetu sintaksu i rješavaju brojne poteškoće this. Dajte prednost funkcijama strelice nad functionključnom riječi, posebno za ugniježđene funkcije

Bit ću iskren, samo sam mislio da su funkcije strelica izvrsne jer su sažetije i ljepše ih je gledati. Ispostavilo se da imaju i prilično važnu svrhu.

// 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;});

Upotrijebite nizove predložaka umjesto spajanja

Upotrijebite nizove predložaka (odvojene s `) za složeno spajanje nizova, posebno ako je u pitanju više literalnih nizova. Niz predložaka može obuhvaćati više redaka.
// 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}?`;}

Ne koristite nastavke reda za duge nizove

Nemojte koristiti nastavke redaka (to jest, završavanje retka unutar znakovnog niza s kosom crtom) ni u običnom ni u predložaknom literalnom nizu. Iako ES5 to dopušta, to može dovesti do nezgodnih pogrešaka ako bilo koji zaostali razmak dođe nakon kose crte, a čitateljima je manje očit.

Zanimljivo je da je ovo pravilo oko kojeg se Google i Airbnb ne slažu (evo Airbnb-ovih specifikacija).

Iako Google preporučuje spajanje dužih nizova (kao što je prikazano dolje), Airbnb-ov vodič za stil preporučuje u osnovi ne poduzimati ništa i dopustiti da duge žice traju onoliko dugo koliko trebaju.

// 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.';

"For ... of" je preferirani tip "for loop"

S ES6, jezik sada ima tri različite vrste forpetlji. Mogu se upotrijebiti svi for- ofpetlje trebaju biti poželjne kad god je to moguće.

Ovo je neobično ako mene pitate, ali pomislio sam da bih ga uključio jer je prilično zanimljivo da Google proglašava preferiranu vrstu forpetlje.

Uvijek sam imao dojam da su for... inpetlje bolje za objekte, dok for... ofsu više prikladne za nizove. Pravi alat za pravi posao.

Iako Googleove specifikacije ovdje nisu nužno u suprotnosti s tom idejom, ipak je zanimljivo znati da oni preferiraju posebno ovu petlju.

Nemojte koristiti eval ()

Ne koristite evalniti Function(...string)konstruktor (osim kod učitavača koda). Te su značajke potencijalno opasne i jednostavno ne rade u CSP okruženjima.

MDN stranica eval()čak ima i odjeljak pod nazivom "Ne koristi 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

Konstante bi trebale biti imenovane u ALL_UPPERCASE odvojeno podvlakama

Upotreba stalnih imena CONSTANT_CASE: sva velika slova, s riječima odvojenim donjim crtama.

Ako ste apsolutno sigurni da se varijabla ne bi trebala mijenjati, to možete naznačiti velikim slovom imena konstante. To čini nepromjenjivost konstante očitom jer se koristi u cijelom kodu.

Iznimna iznimka od ovog pravila jest ako je konstanta opsega funkcije. U ovom slučaju to treba napisati u camelCase.

// badconst number = 5;
// goodconst NUMBER = 5;

Jedna varijabla po deklaraciji

Svaka deklaracija lokalne varijable deklarira samo jednu varijablu: deklaracije kakve let a = 1, b = 2;se ne koriste.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Koristite jednostruke navodnike, a ne dvostruke navodnike

Uobičajeni literalni nizovi razdvajaju se jednostrukim navodnicima ( '), a ne dvostrukim navodnicima ( "). Savjet: ako niz sadrži jedan znak navodnika, razmislite o upotrebi niza predloška kako biste izbjegli izbjegavanje citata.
// badlet directive = "No identification of self or mission."
// badlet saying = 'Say it ain\u0027t so.';
// goodlet directive = 'No identification of self or mission.';
// goodlet saying = `Say it ain't so`;

Završna napomena

Kao što sam rekao na početku, to nisu mandati. Google je samo jedan od mnogih tehnoloških divova, a to su samo preporuke.

Ipak, zanimljivo je pogledati preporuke za stil koje donosi tvrtka poput Googlea koja zapošljava puno briljantnih ljudi koji provode puno vremena pišući izvrsni kôd.

You can follow these rules if you want to follow the guidelines for ‘Google compliant source code’ — but, of course, plenty of people disagree, and you’re free to brush any or all of this off.

I personally think there are plenty of cases where Airbnb’s spec is more appealing than Google’s. No matter the stance you take on these particular rules, it is still important to keep stylistic consistency in mind when write any sort of code.