koden vår må være så ren og lett å lese som mulig.

det er faktisk kunsten å programmere – å ta en kompleks oppgave og kode den på en måte som er både korrekt og menneskelig lesbar. En god kodestil bidrar sterkt til det.

Syntaks

her er en jukselapp med noen foreslåtte regler (se nedenfor for flere detaljer):

la oss nå diskutere reglene og årsakene til dem i detalj.

Curly Braces

i De Fleste JavaScript-prosjekter er curly braces skrevet i «Egyptisk» stil med åpningsstøtten på samme linje som det tilsvarende søkeordet – ikke på en ny linje. Det bør også være et mellomrom før åpningsbraketten, slik:

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

En enkeltlinjekonstruksjon, for eksempelif (condition) doSomething(), er et viktig kanttilfelle. Bør vi bruke tannregulering i det hele tatt?

her er de annoterte varianter, slik at du kan bedømme deres lesbarhet for deg selv:

for en veldig kort kode er en linje tillatt, f. eks. if (cond) return null. Men en kodeblokk (den siste varianten) er vanligvis mer lesbar.

Linjelengde

Ingen liker å lese en lang horisontal linje med kode. Det er best praksis å dele dem.

For eksempel:

// 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, Forifuttalelser:

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

maksimal linjelengde bør avtales på lagnivå. Det er vanligvis 80 eller 120 tegn.

Innrykk

Det finnes to typer innrykk:

• Horisontale innrykk: 2 eller 4 mellomrom.

  en horisontal innrykk gjøres med enten 2 eller 4 mellomrom eller det horisontale tabulatorsymbolet (nøkkelfane). Hvilken du skal velge er en gammel hellig krig. Mellomrom er mer vanlig i dag.

  en fordel med mellomrom over faner er at mellomrom tillater mer fleksible konfigurasjoner av innrykk enn tab-symbolet.

  for eksempel kan vi justere parametrene med åpningsbraketten, slik:

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

• Vertikale innrykk: tomme linjer for å dele kode i logiske blokker.

  Selv en enkelt funksjon kan ofte deles inn i logiske blokker. I eksemplet nedenfor er initialiseringen av variabler, hovedløkken og returresultatet delt vertikalt:

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

  Sett inn en ekstra ny linje der det bidrar til å gjøre koden mer lesbar. Det bør ikke være mer enn ni linjer med kode uten vertikal innrykk.

Semikolon

et semikolon bør være til stede etter hver setning, selv om det muligens kan hoppes over.

det er språk der et semikolon er virkelig valgfritt, og det brukes sjelden. I JavaScript er det imidlertid tilfeller der et linjeskift ikke tolkes som et semikolon, noe som gjør koden sårbar for feil. Se mer om Det i kapittelet Kodestruktur.

hvis Du er en erfaren JavaScript-programmerer, kan du velge en ikke-semikolon kodestil Som StandardJS. Ellers er det best å bruke semikolon for å unngå mulige fallgruver. De fleste utviklere legger semikolon.

Hekkende Nivåer

Prøv å unngå å hekke kode for mange nivåer dypt.

for eksempel i løkken er det noen ganger lurt å bruke continue direktivet for å unngå ekstra nesting.

for eksempel, i stedet for å legge til en nestet if betinget som dette:

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

:

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

En lignende ting kan gjøres medif/elseogreturn.

for eksempel er to konstruksjoner nedenfor identiske.

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

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

den andre er mer lesbar fordi «spesialtilfellet» av n < 0 håndteres tidlig. Når sjekken er ferdig, kan vi gå videre til» hoved » kodestrømmen uten behov for ytterligere nesting.

Funksjonsplassering

hvis du skriver flere» hjelper » – funksjoner og koden som bruker dem, er det tre måter å organisere funksjonene på.

Mesteparten av tiden er den andre varianten foretrukket.

Det er fordi når vi leser kode, vil vi først vite hva den gjør. Hvis koden går først, blir det klart fra starten. Da trenger vi kanskje ikke å lese funksjonene i det hele tatt, spesielt hvis navnene deres er beskrivende for hva de faktisk gjør.

Stilveiledninger

en stilveiledning inneholder generelle regler om» hvordan skrive » kode, f.eks. hvilke anførselstegn som skal brukes, hvor mange mellomrom som skal rykke inn, maksimal linjelengde osv. Mange mindre ting.

når alle medlemmer av et team bruker samme stilguide, ser koden ut som den er ensartet, uavhengig av hvilket teammedlem som skrev den.

selvfølgelig kan et lag alltid skrive sin egen stilguide, men vanligvis er det ikke nødvendig. Det er mange eksisterende guider å velge mellom.

Noen populære valg:

• Google JavaScript Style Guide
• Airbnb JavaScript Style Guide
• Idiomatisk.Js
• StandardJS
• (pluss mange flere)

hvis du er en nybegynner utvikler, starte med jukselapp i begynnelsen av dette kapittelet. Deretter kan du bla gjennom andre stilguider for å hente flere ideer og bestemme hvilken du liker best.

Automatiserte Linters

Linters Er verktøy som automatisk kan sjekke stilen på koden din og gjøre bedre forslag.det som er bra med dem er at stilkontroll også kan finne noen feil, som skrivefeil i variable eller funksjonsnavn. På grunn av denne funksjonen anbefales det å bruke en linter selv om du ikke vil holde fast i en bestemt «kodestil».

Her er noen kjente linting verktøy:

• JSLint-en av de første linters.
• JSHint – flere innstillinger Enn JSLint.
• ESLint-sannsynligvis den nyeste.

Alle av dem kan gjøre jobben. Forfatteren bruker ESLint.

de fleste linters er integrert med mange populære redaktører: bare aktiver pluginet i editoren og konfigurer stilen.

For Eksempel, For ESLint bør du gjøre følgende:

1. Installer Node.js.
2. Installer ESLint med kommandoen npm install -g eslint (npm er En JavaScript-pakkeinstallatør).
3. Opprett en config-fil som heter .eslintrc i Roten Til JavaScript-prosjektet ditt (i mappen som inneholder alle filene dine).
4. Installer / aktiver plugin for redaktøren din som 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 direktivet"extends"angir at konfigurasjonen er basert på «eslint:anbefalt» sett med innstillinger. Etter det spesifiserer vi vår egen.

det er også mulig å laste ned stilregelsett fra nettet og utvide dem i stedet. Se http://eslint.org/docs/user-guide/getting-started for mer informasjon om installasjon.

også visse Ide har innebygd linting, som er praktisk, men ikke så tilpassbar som ESLint.

Sammendrag

alle syntaksregler som er beskrevet i dette kapittelet (og i stilguidene det refereres til) tar sikte på å øke lesbarheten til koden din. Alle av dem er diskutable.

når vi tenker på å skrive» bedre «kode, er spørsmålene vi bør stille oss selv:» Hva gjør koden mer lesbar og lettere å forstå?»og» hva kan hjelpe oss med å unngå feil?»Dette er de viktigste tingene å huske på når du velger og diskuterer kodestiler.

Lese populære stil guider vil tillate deg å holde deg oppdatert med de nyeste ideene om kode stil trender og beste praksis.