if (condition) { // do this // ...and that // ...and that}

een constructie met één regel, zoals if (condition) doSomething(), is een belangrijk randgeval. Moeten we een beugel gebruiken?

Hier zijn de geannoteerde varianten zodat u hun leesbaarheid zelf kunt beoordelen:

voor een zeer korte code is één regel toegestaan, bijvoorbeeld if (cond) return null. Maar een code blok (de laatste variant) is meestal beter leesbaar.

regellengte

niemand leest graag een lange horizontale code. Het is het beste om ze te splitsen.

bijvoorbeeld:

// backtick quotes ` allow to split the string into multiple lineslet str = ` ECMA International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript.`;

en, voor if statements:

if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}

De maximale lijnlengte moet op teamniveau worden overeengekomen. Het zijn meestal 80 of 120 karakters.

inspringingen

er zijn twee typen inspringingen:

• horizontale inspringingen: 2 of 4 spaties.

  een horizontale inspringing wordt gemaakt met 2 of 4 spaties of het horizontale tabsymbool (tabblad toetsen). Welke te kiezen is een oude heilige oorlog. Ruimtes komen tegenwoordig vaker voor.

  een voordeel van spaties boven tabs is dat spaties flexibeler configuraties van inspringingen toestaan dan het tabsymbool.

  bijvoorbeeld, we kunnen de parameters uitlijnen met de openingshaakje, als volgt:

  show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}

• verticale inspringingen: lege regels voor het splitsen van code in logische blokken.

  zelfs een enkele functie kan vaak worden onderverdeeld in logische blokken. In het onderstaande voorbeeld worden de initialisatie van variabelen, de hoofdlus en het retourneren van het resultaat verticaal gesplitst:

  function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}

  voeg een extra nieuwe regel in waar het helpt om de code leesbaarder te maken. Er mogen niet meer dan negen regels code zijn zonder een verticale inspringing.

puntkomma ‘ s

na elk statement moet een puntkomma aanwezig zijn, zelfs als het mogelijk zou kunnen worden overgeslagen.

Er zijn talen waarin een puntkomma echt optioneel is en zelden wordt gebruikt. In JavaScript zijn er echter gevallen waarin een regeleinde niet wordt geïnterpreteerd als een puntkomma, waardoor de code kwetsbaar is voor fouten. Zie meer hierover in het hoofdstuk Code structuur.

als u een ervaren JavaScript-programmeur bent, kunt u een no-puntkomma-codestijl kiezen zoals Standaardjs. Anders is het het beste om puntkomma ‘ s te gebruiken om mogelijke valkuilen te vermijden. De meerderheid van ontwikkelaars stellen puntkomma ‘ s in.

Nestniveaus

probeer te voorkomen dat de nestcode te veel niveaus diep is.

bijvoorbeeld, in de lus is het soms een goed idee om de continue richtlijn te gebruiken om extra nesting te voorkomen.

bijvoorbeeld, in plaats van het toevoegen van een geneste if conditioneel als volgt:

for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}

kunnen we schrijven:

for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}

een soortgelijk ding kan worden gedaan met if/elseenreturn.

bijvoorbeeld, twee onderstaande constructies zijn identiek.

Optie 1:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); } else { let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result; }}

Optie 2:

function pow(x, n) { if (n < 0) { alert("Negative 'n' not supported"); return; } let result = 1; for (let i = 0; i < n; i++) { result *= x; } return result;}

de tweede is meer leesbaar omdat het “speciale geval” van n < 0vroeg wordt afgehandeld. Zodra de controle is gedaan kunnen we verder gaan met de “main” code flow zonder de noodzaak voor extra nesting.

Function Placement

Als u meerdere “helper” functies schrijft en de code die ze gebruikt, zijn er drie manieren om de functies te organiseren.

meestal heeft de tweede variant de voorkeur.

dat komt omdat we bij het lezen van code eerst willen weten wat het doet. Als de code eerst gaat, dan wordt het vanaf het begin duidelijk. Dan, misschien hoeven we de functies helemaal niet te lezen, vooral als hun namen beschrijvend zijn van wat ze eigenlijk doen.

Style Guides

een style guide bevat algemene regels over” hoe te schrijven ” code, bijvoorbeeld welke aanhalingstekens moeten worden gebruikt, hoeveel spaties moeten worden ingesprongen, de maximale regellengte, enz. Veel kleine dingen.

wanneer alle leden van een team dezelfde stijlgids gebruiken, ziet de code er uniform uit, ongeacht welk teamlid het schreef.

natuurlijk kan een team altijd een eigen stijlgids schrijven, maar dat is meestal niet nodig. Er zijn veel bestaande gidsen om uit te kiezen.

enkele populaire keuzes:

• Google JavaScript Style Guide
• Airbnb JavaScript Style Guide
• Idiomatic.Js
• Standaardjs
• (plus nog veel meer)

Als u een beginnende ontwikkelaar bent, begin dan met het spiekbriefje aan het begin van dit hoofdstuk. Dan kunt u bladeren andere stijl gidsen op te halen meer ideeën en beslissen welke u het beste bevalt.

geautomatiseerde Linters

Linters zijn hulpmiddelen die automatisch de stijl van uw code kunnen controleren en verbeterende suggesties kunnen doen.

het mooie aan hen is dat style-checking ook enkele bugs kan vinden, zoals typefouten in variabele of functienamen. Vanwege deze functie, het gebruik van een linter wordt aanbevolen, zelfs als u niet wilt vasthouden aan een bepaalde “code stijl”.

Hier zijn enkele bekende linting tools:

• JSLint-een van de eerste linters.
• JSHint – Meer instellingen dan JSLint.
• ESLint-waarschijnlijk de nieuwste.

allen kunnen de taak uitvoeren. De auteur gebruikt ESLint.

De meeste linters zijn geïntegreerd met veel populaire editors: schakel gewoon de plugin in de editor en configureer de stijl.

bijvoorbeeld, voor ESLint moet u het volgende doen:

1. Install Node.js.
2. installeer ESLint met het commando npm install -g eslint (npm is een JavaScript-pakketinstallatieprogramma).
3. Maak een configuratiebestand aan met de naam .eslintrc in de root van uw JavaScript-project (in de map die al uw bestanden bevat).
4. installeer / activeer de plugin voor uw editor die integreert met ESLint. De meeste redacteuren hebben er een.

Hier is een voorbeeld van een .eslintrc bestand:

{ "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}

Hier geeft de richtlijn "extends"aan dat de configuratie is gebaseerd op de set instellingen” eslint:recommended”. Daarna specificeren we onze eigen.

Het is ook mogelijk om stijlregelsets van het web te downloaden en in plaats daarvan uit te breiden. Zie http://eslint.org/docs/user-guide/getting-started voor meer details over de installatie.

ook bepaalde IDEs hebben ingebouwde linting, wat handig is, maar niet zo aanpasbaar als ESLint.

samenvatting

alle syntaxisregels die in dit hoofdstuk worden beschreven (en in de stijlgidsen waarnaar wordt verwezen) zijn bedoeld om de leesbaarheid van uw code te vergroten. Ze zijn allemaal discutabel.

wanneer we denken aan het schrijven van “betere” code, moeten we onszelf de volgende vragen stellen: “wat maakt de code leesbaarder en gemakkelijker te begrijpen?”en” wat kan ons helpen fouten te voorkomen?”Dit zijn de belangrijkste dingen om in gedachten te houden bij het kiezen en debatteren code stijlen.

het lezen van populaire stijlgidsen stelt u in staat om op de hoogte te blijven van de laatste ideeën over trends in codestijl en best practices.