13 huomionarvoista pistettä Googlen JavaScript-tyylioppaasta

Kaikille, jotka eivät vielä ole perehtyneet siihen, Google julkaisee tyylin oppaan JavaScriptin kirjoittamiseen, jossa esitetään (mitä Google uskoo olevan) parhaat tyylikäytännöt puhtaan, ymmärrettävän koodin kirjoittamiseksi.

Nämä eivät ole kovia ja nopeita sääntöjä kelvollisen JavaScriptin kirjoittamiseen, vain kiellot yhtenäisten ja houkuttelevien tyylivalintojen ylläpitämiseksi lähdetiedostoissasi. Tämä on erityisen mielenkiintoista JavaScriptille, joka on joustava ja anteeksiantava kieli, joka sallii monenlaiset tyylivalinnat.

Googlella ja Airbnb: llä on kaksi suosituinta tyyliopasta. Suosittelen ehdottomasti tutustumaan molempiin, jos vietät paljon aikaa JS: n kirjoittamiseen.

Seuraavassa on kolmetoista mielestäni mielenkiintoisimpia ja olennaisimpia sääntöjä Googlen JS Style Guide -oppaasta.

He käsittelevät kaikkea kiistanalaisista asioista (välilehdet vs. välilyönnit ja kiistanalainen kysymys siitä, kuinka puolipisteitä tulisi käyttää), muutamaan vielä hämärään määritykseen, jotka yllättivät minut. Ne muuttavat ehdottomasti tapaa, jolla kirjoitan JS: n eteenpäin.

Annan jokaiselle säännölle yhteenvedon erittelystä, jota seuraa tukisitaatti tyylioppaasta, joka kuvaa sääntöä yksityiskohtaisesti. Tarvittaessa annan myös esimerkin tyylistä käytännössä ja verran sitä koodiin, joka ei noudata sääntöä.

Käytä välilyöntejä, ei sarkaimia

Rivin lopetusjakson lisäksi ASCII-vaakatilamerkki (0x20) on ainoa välilyönti, joka näkyy missä tahansa lähdetiedostossa. Tämä tarkoittaa, että… Sarkainmerkkejä ei käytetä sisennykseen.

Opas määrittelee myöhemmin, että sisennykseen tulee käyttää kahta välilyöntiä (ei neljää).

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

Pisteitä tarvitaan

Jokainen lause on lopetettava puolipisteellä. Autuminen puolipisteen automaattiseen lisäykseen on kielletty.

Vaikka en voi kuvitella, miksi kukaan vastustaa tätä ajatusta, puolipisteiden johdonmukaisesta käytöstä JS: ssä on tulossa uusi keskustelu "välilyöntejä vastaan ​​välilehdet". Google tulee tiukasti esiin puolipisteen puolustuksessa.

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

Älä käytä ES6-moduuleja (vielä)

Älä käytä vielä ES6-moduuleja (ts. exportJa importavainsanoja), koska niiden semantiikkaa ei ole vielä viimeistelty. Huomaa, että tätä käytäntöä tarkastellaan uudelleen, kun semantiikka on täysin vakio.
// 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';

Vaakasuuntaista suuntausta ei suositella (mutta ei kielletty)

Tämä käytäntö on sallittu, mutta Google Style ei yleensä suosittele sitä. Vaakatasoa ei tarvitse edes pitää yllä paikoissa, joissa sitä jo käytettiin.

Vaakatasaus on käytäntö lisätä muuttuvan määrän ylimääräisiä välilyöntejä koodiin, jotta tietyt tunnukset näkyvät suoraan tiettyjen muiden tunnusten alapuolella edellisillä riveillä.

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

Älä käytä varia enää

Ilmoita kaikki paikalliset muuttujat joko consttai let. Käytä const oletuksena, ellei muuttujaa tarvitse määrittää uudelleen. varAvainsanaa ei saa käyttää.

Näen edelleen ihmisiä käyttävän varkoodinäytteissä StackOverflow'ssa ja muualla. En voi kertoa, onko siellä ihmisiä, jotka tekevät asiasta asian vai onko kyse vain vanhojen tapojen kuolemasta kovasti.

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

Nuolitoiminnot ovat suositeltavia

Nuolitoiminnot tarjoavat tiiviin syntaksin ja korjaavat useita vaikeuksia this. Mieluummin nuolitoiminnot functionavainsanan sijaan, erityisesti sisäkkäisissä toiminnoissa

Olen rehellinen, ajattelin vain, että nuolitoiminnot olivat hienoja, koska ne olivat ytimekkäämpiä ja mukavampia katsella. Osoittautuu, että niillä on myös melko tärkeä tarkoitus.

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

Käytä mallijonoja ketjutuksen sijaan

Käytä mallijonoja (erotettu `) monimutkaisten merkkijonojen ketjutuksessa, varsinkin jos mukana on useita merkkijonolitraaleja. Mallimerkkijonot voivat ulottua usealle riville.
// 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}?`;}

Älä käytä viivan jatkoa pitkille jousille

Älä käytä viivan jatkoa (ts. Merkkijonolitrauksen sisällä olevan rivin päättämistä taaksepäin) joko tavallisissa tai mallimerkkijonolitraaleissa. Vaikka ES5 sallii tämän, se voi johtaa hankaliin virheisiin, jos jäljellä oleva välilyönti tulee kauttaviivan jälkeen ja on vähemmän ilmeinen lukijoille.

Kiinnostavaa kyllä, tämä on sääntö, josta Google ja Airbnb ovat eri mieltä (tässä Airbnb: n tekniset tiedot).

Vaikka Google suosittelee pidempien merkkijonojen liittämistä (kuten alla on esitetty), Airbnb: n tyylioppaassa suositellaan olennaisesti tekemättä mitään ja sallimalla pitkien merkkijonojen jatkuminen niin kauan kuin heidän tarvitsee.

// 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" on ensisijainen "for loop" -tyyppi

ES6: lla kielellä on nyt kolme erilaista forsilmukkaa. Kaikkia voidaan kuitenkin käyttää for- ofsilmukoita tulisi suositella aina kun mahdollista.

Tämä on outo, jos kysyt minulta, mutta ajattelin sisällyttää sen, koska on melko mielenkiintoista, että Google ilmoittaa suositellun forsilmukan tyypin .

Minusta tuntui aina, että for... insilmukat for... ofsopivat paremmin esineille, mutta sopivat paremmin matriiseihin. "Oikea työkalu oikeaan työhön" -tyyppiseen tilanteeseen.

Vaikka Googlen määrittely tässä ei välttämättä ole ristiriidassa tämän idean kanssa, on silti mielenkiintoista tietää, että heillä on etusija erityisesti tällä silmukalla.

Älä käytä eval ()

Älä käytä evaltai Function(...string)rakennuttajaa (paitsi koodikuormaajia). Nämä ominaisuudet ovat mahdollisesti vaarallisia eivätkä yksinkertaisesti toimi CSP-ympäristöissä.

MDN -sivulla on eval()edes kohta nimeltä "Älä käytä evalia!"

// 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

Vakiot tulisi nimetä ALL_UPPERCASE-muodossa erottamalla alleviivat

Jatkuvien nimien käyttö CONSTANT_CASE: kaikki isot kirjaimet, joissa sanat on erotettu alaviivoilla.

Jos olet täysin varma, että muuttujan ei pitäisi muuttua, voit ilmoittaa tämän kirjoittamalla vakion nimen isoilla kirjaimilla. Tämä tekee vakion muuttumattomuuden ilmeiseksi, kun sitä käytetään koko koodissasi.

Huomattava poikkeus tästä säännöstä on, jos vakio on funktion laajuinen. Tässä tapauksessa se tulisi kirjoittaa camelCase.

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

Yksi muuttuja ilmoitusta kohti

Jokainen paikallisen muuttujan ilmoitus ilmoittaa vain yhden muuttujan: ilmoituksia, let a = 1, b = 2;joita ei käytetä.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Käytä yksittäisiä lainausmerkkejä, älä kaksoislainauksia

Tavalliset merkkijonolitraalit on erotettu lainausmerkeillä ( ') kaksoislainausmerkkien ( ") sijasta.
// 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`;

Viimeinen huomautus

Kuten sanoin alussa, nämä eivät ole mandaatteja. Google on vain yksi monista tekniikan jättiläisistä, ja nämä ovat vain suosituksia.

Tästä huolimatta on mielenkiintoista tarkastella tyylisuosituksia, jotka on antanut Google-tyyppinen yritys, joka työllistää paljon loistavia ihmisiä, jotka käyttävät paljon aikaa erinomaisen koodin kirjoittamiseen.

Voit noudattaa näitä sääntöjä, jos haluat noudattaa Google-yhteensopivan lähdekoodin ohjeita - mutta tietysti monet ihmiset ovat eri mieltä, ja voit vapaasti harjata kaiken tai kaiken tämän.

Henkilökohtaisesti mielestäni on paljon tapauksia, joissa Airbnb: n tekniset tiedot ovat houkuttelevampia kuin Google. Riippumatta siitä, miten suhtaudut näihin sääntöihin, on silti tärkeää pitää mielessä tyylinen yhdenmukaisuus kirjoittaessasi minkäänlaista koodia.