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

og forif erklæringer:

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

den maksimale linjelængde skal aftales på holdniveau. Det er normalt 80 eller 120 tegn.

indrykninger

der er to typer indrykninger:

• vandrette indrykninger: 2 eller 4 mellemrum.

  en vandret indrykning foretages ved hjælp af enten 2 eller 4 mellemrum eller det vandrette fanesymbol (tast Tab). Hvilken man skal vælge er en gammel hellig krig. Rum er mere almindelige i dag.

  en fordel ved mellemrum i forhold til faner er, at mellemrum tillader mere fleksible konfigurationer af indrykninger end fanesymbolet.

  for eksempel kan vi justere parametrene med åbningsbeslaget som dette:

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

• lodrette indrykninger: tomme linjer til opdeling af kode i logiske blokke.

  selv en enkelt funktion kan ofte opdeles i logiske blokke. I eksemplet nedenfor opdeles initialiseringen af variabler, hovedsløjfen og returnering af resultatet lodret:

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

  indsæt en ekstra nylinje, hvor det hjælper med at gøre koden mere læsbar. Der bør ikke være mere end ni linjer kode uden en lodret indrykning.

  semikolon

  et semikolon skal være til stede efter hver sætning, selvom det muligvis kunne springes over.

  der er sprog, hvor et semikolon virkelig er valgfrit, og det bruges sjældent. I JavaScript er der dog tilfælde, hvor et linjeskift ikke fortolkes som et semikolon, hvilket efterlader koden sårbar over for fejl. Se mere om det i kapitlet Kodestruktur.

  Hvis du er en erfaren JavaScript-programmør, kan du vælge en no-semikolon kode stil som StandardJS. Ellers er det bedst at bruge semikoloner for at undgå mulige faldgruber. De fleste udviklere sætter semikoloner.

  Nesting niveauer

  prøv at undgå nesting kode for mange niveauer dybt.

  for eksempel i sløjfen er det nogle gange en god ide at bruge continue direktivet for at undgå ekstra nesting.

  for eksempel i stedet for at tilføje en indlejret if betinget som dette:

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

  Vi kan skrive:

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

  en lignende ting kan gøres med if/else og return.

  for eksempel er to konstruktioner nedenfor identiske.

  valgmulighed 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; }}

  valgmulighed 2:

  en anden er mere læsbar, fordi”special case”af n < 0 håndteres tidligt. Når kontrollen er udført, kan vi gå videre til “hoved” kodestrømmen uden behov for yderligere indlejring.

  Funktionsplacering

  Hvis du skriver flere “hjælper” – funktioner og koden, der bruger dem, er der tre måder at organisere funktionerne på.

  det meste af tiden foretrækkes den anden variant.

  det skyldes, at når vi læser kode, vil vi først vide, hvad den gør. Hvis koden går først, bliver det klart fra starten. Derefter behøver vi måske ikke at læse funktionerne overhovedet, især hvis deres navne er beskrivende for, hvad de rent faktisk gør.

  stilguider

  en stilguide indeholder generelle regler om “hvordan man skriver” – kode, f.eks. hvilke citater der skal bruges, hvor mange mellemrum der skal indrykkes, den maksimale linjelængde osv. En masse mindre ting.

  når alle medlemmer af et team bruger den samme typografiguide, ser koden ensartet ud, uanset hvilket teammedlem der skrev den.

  selvfølgelig kan et hold altid skrive deres egen stilguide, men det er normalt ikke nødvendigt. Der er mange eksisterende guider at vælge imellem.

  nogle populære valg:

  • Google JavaScript Style Guide
  • Airbnb JavaScript Style Guide
  • idiomatisk.JS
  • StandardJS
  • (plus mange flere)

  Hvis du er en nybegynder udvikler, skal du starte med snydearket i begyndelsen af dette kapitel. Derefter kan du gennemse andre stilguider for at hente flere ideer og beslutte, hvilken du bedst kan lide.

  automatiserede Linters

  Linters er værktøjer, der automatisk kan kontrollere stilen på din kode og komme med forbedrende forslag.

  det gode ved dem er, at stilkontrol også kan finde nogle fejl, som skrivefejl i variable eller funktionsnavne. På grund af denne funktion anbefales det at bruge en linter, selvom du ikke vil holde dig til en bestemt “kodestil”.

  Her er nogle kendte linting værktøjer:

  • JSLint-en af de første linters.
  • JSHint – flere indstillinger end JSLint.
  • ESLint-sandsynligvis den nyeste.

  alle kan gøre jobbet. Forfatteren bruger ESLint.

  de fleste linters er integreret med mange populære redaktører: bare aktivere plugin i editoren og konfigurere stil.

  for eksempel skal du for ESLint gøre følgende:

  1. Install Node.js.
  2. installer ESLint med kommandoen npm install -g eslint (npm er et JavaScript-Pakkeinstallationsprogram).
  3. Opret en konfigurationsfil med navnet .eslintrc i roden til dit JavaScript-projekt (i den mappe, der indeholder alle dine filer).
  4. installer / Aktiver plugin til din editor, der integreres med ESLint. De fleste redaktører har en.

  Her er et eksempel på en .eslintrc fil:

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

  Her angiver direktivet"extends", at konfigurationen er baseret på “eslint:recommended” sæt indstillinger. Derefter angiver vi vores egne.

  det er også muligt at hente stil regel sæt fra internettet og udvide dem i stedet. Se http://eslint.org/docs/user-guide/getting-started for flere detaljer om installation.

  også visse ide ‘ er har indbygget linting, hvilket er praktisk, men ikke så tilpasseligt som ESLint.

  oversigt

  alle syntaksregler, der er beskrevet i dette kapitel (og i stilvejledningerne, der henvises til), sigter mod at øge læsbarheden af din kode. Alle af dem kan diskuteres.

  når vi tænker på at skrive” bedre ” kode, er de spørgsmål, vi skal stille os selv: “Hvad gør koden mere læsbar og lettere at forstå?”og” hvad kan hjælpe os med at undgå fejl?”Dette er de vigtigste ting, du skal huske på, når du vælger og diskuterer kodestilarter.

  læsning af populære stilguider giver dig mulighed for at holde dig opdateret med de nyeste ideer om kodestil trends og bedste praksis.