13 bemærkelsesværdige punkter fra Googles JavaScript Style Guide

For alle, der ikke allerede er fortrolige med det, udarbejder Google en stilvejledning til at skrive JavaScript, der beskriver (hvad Google mener er) de bedste stilistiske fremgangsmåder til at skrive ren, forståelig kode.

Disse er ikke hårde og hurtige regler til skrivning af gyldig JavaScript, kun påbud for at opretholde ensartede og tiltalende stilvalg i dine kildefiler. Dette er især interessant for JavaScript, som er et fleksibelt og tilgivende sprog, der giver mulighed for en bred vifte af stilistiske valg.

Google og Airbnb har to af de mest populære stilguider derude. Jeg vil bestemt anbefale dig at tjekke dem begge, hvis du bruger meget tid på at skrive JS.

Følgende er tretten af, hvad jeg synes er de mest interessante og relevante regler fra Googles JS Style Guide.

De beskæftiger sig med alt fra meget anfægtede problemer (faner versus mellemrum og det kontroversielle spørgsmål om, hvordan semikoloner skal bruges) til et par mere uklare specifikationer, der overraskede mig. De vil helt sikkert ændre den måde, jeg skriver min JS fremadrettet på.

For hver regel giver jeg et resumé af specifikationen efterfulgt af et understøttende citat fra stilguiden, der beskriver reglen i detaljer. Hvor det er relevant, giver jeg også et eksempel på stilen i praksis og kontrasterer den med kode, der ikke følger reglen.

Brug mellemrum, ikke faner

Bortset fra linjetermineringssekvensen er ASCII vandret mellemrumstegn (0x20) det eneste hvide mellemrumstegn, der vises overalt i en kildefil. Dette indebærer, at ... Tabtegn ikke bruges til indrykning.

Guiden angiver senere, at du skal bruge to mellemrum (ikke fire) til indrykning.

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

Der kræves semikolon

Hver erklæring skal afsluttes med et semikolon. At stole på automatisk indsættelse af semikolon er forbudt.

Selvom jeg ikke kan forestille mig, hvorfor nogen er imod denne idé, bliver den konsekvente brug af semikolon i JS den nye debat om "mellemrum versus faner". Google kommer fast ud her til forsvar for semikolonet.

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

Brug ikke ES6-moduler (endnu)

Brug ikke ES6-moduler endnu (dvs. exportog importnøgleordene), da deres semantik endnu ikke er afsluttet. Bemærk, at denne politik vil blive revideret igen, når semantikken er fuldt 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';

Vandret tilpasning frarådes (men ikke forbudt)

Denne praksis er tilladt, men det frarådes generelt af Google Style. Det er ikke engang nødvendigt at opretholde vandret justering på steder, hvor den allerede blev brugt.

Vandret justering er den praksis at tilføje et variabelt antal ekstra mellemrum i din kode for at få bestemte tokens til at vises direkte under visse andre tokens på tidligere linjer.

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

Brug ikke var mere

Erklær alle lokale variabler med enten consteller let. Brug const som standard, medmindre en variabel skal tildeles igen. Den varsøgeordet må ikke anvendes.

Jeg ser stadig folk, der bruger vari kodeeksempler på StackOverflow og andre steder. Jeg kan ikke fortælle, om der er mennesker derude, der vil argumentere for det, eller om det bare er et tilfælde af gamle vaner, der dør hårdt.

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

Pilfunktioner foretrækkes

Pile-funktioner giver en kortfattet syntaks og løser en række vanskeligheder med this. Foretrækker pilfunktioner frem for functionnøgleordet, især for indlejrede funktioner

Jeg vil være ærlig, jeg troede bare, at pilfunktionerne var gode, fordi de var mere koncise og pænere at se på. Det viser sig, at de også tjener et ret vigtigt formål.

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

Brug skabelonstrenge i stedet for sammenkædning

Brug skabelonstrenge (afgrænset med `) over kompleks streng sammenkædning, især hvis flere strenglitteraturer er involveret. Skabelonstrenge kan strække sig over flere linjer.
// 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}?`;}

Brug ikke linjefortsætninger til lange strenge

Brug ikke linjefortsætninger (dvs. slutning af en linje inde i en streng bogstavelig med et tilbageslag) i hverken almindelige eller skabelonstrengsbogstaver. Selvom ES5 tillader dette, kan det føre til vanskelige fejl, hvis noget efterfølgende mellemrum kommer efter skråstreg og er mindre indlysende for læserne.

Interessant nok er dette en regel, som Google og Airbnb er uenige om (her er Airbnbs spec).

Mens Google anbefaler at sammenkæde længere strenge (som vist nedenfor) anbefaler Airbnbs stilguide i det væsentlige at gøre ingenting og lade lange strenge fortsætte, så længe de har brug for det.

// 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 ... af" er den foretrukne type "for loop"

Med ES6 har sproget nu tre forskellige slags forsløjfer. Alt kan bruges, selvom for- ofsløjfer bør foretrækkes, når det er muligt.

Dette er underligt, hvis du spørger mig, men jeg troede, jeg ville medtage det, fordi det er ret interessant, at Google erklærer en foretrukken type forløkke.

Jeg var altid under det indtryk, at for... insløjfer var bedre til objekter, mens de for... ofvar bedre egnet til arrays. Et 'rigtigt værktøj til den rigtige jobtypesituation.

Mens Googles specifikation her ikke nødvendigvis modsiger den idé, er det stadig interessant at vide, at de især foretrækker denne løkke.

Brug ikke eval ()

Brug ikke evaleller Function(...string)konstruktøren (undtagen kodeindlæsere). Disse funktioner er potentielt farlige og fungerer simpelthen ikke i CSP-miljøer.

MDN-siden for eval()endda har et afsnit kaldet "Brug ikke 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

Konstanter skal navngives i ALL_UPPERCASE adskilt af understregninger

Brug af konstante navne CONSTANT_CASE: alle store bogstaver med ord adskilt med understregning.

Hvis du er helt sikker på, at en variabel ikke skal ændres, kan du angive dette ved at bruge navnet på konstanten. Dette gør konstantens uforanderlighed åbenbar, da den bliver brugt i hele din kode.

En bemærkelsesværdig undtagelse fra denne regel er, hvis konstanten er funktionsomfanget. I dette tilfælde skal det skrives i camelCase.

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

En variabel pr. Erklæring

Hver lokal variabelerklæring erklærer kun en variabel: erklæringer som let a = 1, b = 2;ikke bruges.
// badlet a = 1, b = 2, c = 3;
// goodlet a = 1;let b = 2;let c = 3;

Brug enkelt tilbud, ikke dobbelt tilbud

Almindelige strenglitteraturer er afgrænset med enkelt anførselstegn ( ') snarere end dobbelt anførselstegn ( "). Tip: Hvis en streng indeholder et enkelt anførselstegn, skal du overveje at bruge en skabelonstreng for at undgå at skulle undslippe citatet.
// 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`;

En sidste note

Som jeg sagde i starten, er dette ikke mandater. Google er blot en af ​​mange tech-giganter, og det er bare anbefalinger.

Når det er sagt, er det interessant at se på de stilanbefalinger, der er fremsat af et firma som Google, der beskæftiger mange strålende mennesker, der bruger meget tid på at skrive fremragende kode.

Du kan følge disse regler, hvis du vil følge retningslinjerne for 'Google-kompatibel kildekode' - men selvfølgelig er mange mennesker uenige, og du er fri til at børste alt dette eller alt dette af.

Jeg synes personligt, at der er masser af tilfælde, hvor Airbnbs spec er mere tiltalende end Googles. Uanset hvilken holdning du tager på disse særlige regler, er det stadig vigtigt at holde stilistisk konsistens i tankerne, når du skriver nogen form for kode.