Kodningsstil
vår kod måste vara så ren och lättläst som möjligt.
det är faktiskt konsten att programmera – att ta en komplex uppgift och koda den på ett sätt som är både korrekt och mänskligt läsbart. En bra kodstil hjälper mycket i det.
Syntax
här är ett fuskblad med några föreslagna regler (se nedan för mer information):
låt oss nu diskutera reglerna och orsakerna till dem i detalj.
ingenting är satt i sten här. Dessa är stilpreferenser, inte religiösa dogmer.
Curly Braces
i de flesta JavaScript – projekt är curly braces skrivna i ”egyptisk” stil med öppningsstödet på samma rad som motsvarande nyckelord-inte på en ny rad. Det bör också finnas ett mellanslag före öppningsfästet, så här:
if (condition) { // do this // ...and that // ...and that}en enkelradig konstruktion, till exempel if (condition) doSomething(), är ett viktigt kantfall. Ska vi använda hängslen alls?
Här är de kommenterade varianterna så att du kan bedöma deras läsbarhet för dig själv:
för en mycket kort kod är en rad tillåten, t.ex. if (cond) return null. Men ett kodblock (den sista varianten) är vanligtvis mer läsbar.
radlängd
Ingen gillar att läsa en lång horisontell kodrad. Det är bästa praxis att dela upp dem.
till exempel:
// 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.`;och förif uttalanden:
if ( id === 123 && moonPhase === 'Waning Gibbous' && zodiacSign === 'Libra') { letTheSorceryBegin();}den maximala linjelängden bör avtalas på lagnivå. Det är vanligtvis 80 eller 120 tecken.
indrag
det finns två typer av indrag:
-
horisontella indrag: 2 eller 4 mellanslag.
en horisontell indragning görs med antingen 2 eller 4 mellanslag eller den horisontella fliksymbolen (Tangentfliken). Vilken man ska välja är ett gammalt heligt krig. Utrymmen är vanligare nuförtiden.
en fördel med mellanslag över flikar är att mellanslag tillåter mer flexibla konfigurationer av indrag än fliksymbolen.
till exempel kan vi justera parametrarna med öppningsfästet, så här:
show(parameters, aligned, // 5 spaces padding at the left one, after, another ) { // ...}vertikala indrag: tomma rader för att dela kod i logiska block.
även en enda funktion kan ofta delas in i logiska block. I exemplet nedan delas initialiseringen av variabler, huvudslingan och återkomsten av resultatet vertikalt:
function pow(x, n) { let result = 1; // <-- for (let i = 0; i < n; i++) { result *= x; } // <-- return result;}infoga en extra ny rad där det hjälper till att göra koden mer läsbar. Det bör inte finnas mer än nio rader kod utan vertikal indragning.
semikolon
ett semikolon bör finnas efter varje uttalande, även om det eventuellt kan hoppas över.
det finns språk där ett semikolon verkligen är valfritt och det används sällan. I JavaScript finns det dock fall där en radbrytning inte tolkas som en semikolon, vilket gör att koden är sårbar för fel. Se mer om det i kapitlet kodstruktur.
Om du är en erfaren JavaScript programmerare, kan du välja en no-semikolon kod stil som StandardJS. Annars är det bäst att använda semikolon för att undvika eventuella fallgropar. Majoriteten av utvecklarna sätter semikolon.
Häckningsnivåer
försök att undvika häckningskod för många nivåer djupt.
till exempel i loopen är det ibland bra att användacontinue – direktivet för att undvika extra häckning.
till exempel, istället för att lägga till en kapslad if villkorlig så här:
for (let i = 0; i < 10; i++) { if (cond) { ... // <- one more nesting level }}Vi kan skriva:
for (let i = 0; i < 10; i++) { if (!cond) continue; ... // <- no extra nesting level}en liknande sak kan göras med if/else ochreturn.
till exempel är två konstruktioner nedan identiska.
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;} en andra är mer läsbar eftersom ”specialfallet” av n < 0hanteras tidigt. När kontrollen är klar kan vi gå vidare till ”huvud” kodflödet utan behov av ytterligare häckning.
Funktionsplacering
om du skriver flera” hjälparfunktioner ” och koden som använder dem finns det tre sätt att organisera funktionerna.
För det mesta föredras den andra varianten.
det beror på att när vi läser kod vill vi först veta vad den gör. Om koden går först blir det klart från början. Då kanske vi inte behöver läsa funktionerna alls, särskilt om deras namn är beskrivande för vad de faktiskt gör.
stilguider
en stilguide innehåller allmänna regler om” hur man skriver ” – kod, t.ex. vilka citat som ska användas, hur många mellanslag som ska dras in, maximal linjelängd etc. Många mindre saker.
När alla medlemmar i ett team använder samma stilguide ser koden enhetlig ut, oavsett vilken teammedlem som skrev den.naturligtvis kan ett lag alltid skriva sin egen stilguide, men vanligtvis behöver det inte. Det finns många befintliga guider att välja mellan.
några populära val:
- Google JavaScript Style Guide
- Airbnb JavaScript Style Guide
- Idiomatic.JS
- StandardJS
- (plus många fler)
om du är en nybörjare utvecklare, börja med fuskarket i början av detta kapitel. Sedan kan du bläddra i andra stilguider för att hämta fler förslag och bestämma vilken du gillar bäst.
automatiserade Linters
Linters är verktyg som automatiskt kan kontrollera stilen på din kod och göra förbättringsförslag.
det fantastiska med dem är att stilkontroll också kan hitta några buggar, som stavfel i variabelnamn eller funktionsnamn. På grund av den här funktionen rekommenderas att du använder en linter även om du inte vill hålla dig till en viss ”kodstil”.
Här är några välkända linting verktyg:
- JSLint-en av de första linters.
- JSHint – fler inställningar än JSLint.
- ESLint-förmodligen den nyaste.
alla kan göra jobbet. Författaren använder ESLint.
de flesta linters är integrerade med många populära redaktörer: aktivera bara plugin i redigeraren och konfigurera stilen.
till exempel, för ESLint bör du göra följande:
- installera nod.js.
- installera ESLint med kommandot
npm install -g eslint(npm är ett JavaScript-paketinstallatör). - skapa en konfigurationsfil med namnet
.eslintrcI roten till ditt JavaScript-projekt (i mappen som innehåller alla dina filer). - installera / Aktivera plugin för din redaktör som integreras med ESLint. Majoriteten av redaktörerna har en.
här är ett exempel på en .eslintrc fil:
{ "extends": "eslint:recommended", "env": { "browser": true, "node": true, "es6": true }, "rules": { "no-console": 0, "indent": 2 }}Här anger direktivet"extends" att konfigurationen är baserad på inställningarna ”eslint:recommended”. Därefter anger vi vår egen.
det är också möjligt att ladda ner stilregeluppsättningar från webben och utöka dem istället. Se http://eslint.org/docs/user-guide/getting-started för mer information om installation.
även vissa IDE har inbyggd linting, vilket är bekvämt men inte lika anpassningsbart som ESLint.
sammanfattning
alla syntaxregler som beskrivs i detta kapitel (och i de stilguider som refereras) syftar till att öka läsbarheten för din kod. Alla är diskutabla.
När vi tänker på att skriva” bättre ”kod är de frågor vi bör ställa oss själva:” Vad gör koden mer läsbar och lättare att förstå?”och” vad kan hjälpa oss att undvika fel?”Det här är de viktigaste sakerna att tänka på när man väljer och diskuterar kodstilar.
att läsa populära stilguider gör att du kan hålla dig uppdaterad med de senaste ideerna om kodstiltrender och bästa praxis.