koodimme tulee olla mahdollisimman puhdas ja helppolukuinen.

tuo on itse asiassa ohjelmoinnin taidetta – ottaa monimutkainen tehtävä ja koodata se niin, että se on sekä oikein että ihmisen luettavissa. Hyvä koodi tyyli suuresti auttaa siinä.

syntaksi

tässä on lunttilappu, jossa on joitakin ehdotettuja sääntöjä (katso tarkemmat tiedot alla):

nyt keskustellaan säännöistä ja niiden syistä yksityiskohtaisesti.

kiharaiset henkselit

useimmissa JavaScript – projekteissa kiharaiset henkselit kirjoitetaan ”egyptiläiseen” tyyliin siten, että avaustuki on samalla rivillä kuin vastaava hakusana-Ei uudella rivillä. Myös avauskiinnikkeen edessä pitäisi olla väli, kuten näin:

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

yksirivinen konstruktio, kuten if (condition) doSomething(), on tärkeä reunatapaus. Pitäisikö käyttää hammasrautoja?

tässä on huomautetut variantit, joten voit arvioida niiden luettavuutta itse:

hyvin lyhyelle koodille sallitaan yksi rivi, esim. if (cond) return null. Mutta koodilohko (viimeinen muunnelma) on yleensä luettavampi.

rivin pituus

kukaan ei halua lukea pitkää vaakasuoraa viivakoodia. On hyvä käytäntö jakaa ne.

esimerkiksi:

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

ja if lausunnot:

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

maksimipituus tulisi sopia joukkuetasolla. Se on yleensä 80 tai 120 merkkiä.

sisennyksiä

on kahdenlaisia:

• vaakasuoria sisennyksiä: 2 tai 4 välilyöntiä.

  horisontaalinen sisennys tehdään käyttämällä joko 2 tai 4 välilyöntiä tai horisontaalista välilehtisymbolia (key Tab). Kumpi valitaan, on vanha pyhä sota. Tilat ovat nykyään yleisempiä.

  yksi välilyöntien etu välilehtiin nähden on se, että välilyönnit mahdollistavat joustavammat luetelmakohdat kuin välilehtisymboli.

  esimerkiksi parametrit voidaan tasata avaussulkuun, näin:

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

pystysuuntaiset sisennykset: tyhjät rivit koodin jakamiseksi loogisiin lohkoihin.

yksikin funktio voidaan usein jakaa loogisiin lohkoihin. Alla olevassa esimerkissä muuttujien alustus, pääsilmukka ja tuloksen palautus jaetaan pystysuunnassa:

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

Lisää ylimääräinen uusi rivi, jossa se auttaa koodin luettavuutta. Koodia ei saa olla enempää kuin yhdeksän riviä ilman pystysuuntaista sisennystä.

puolipisteet

jokaisen lausuman jälkeen tulee olla puolipiste, vaikka se voitaisiin mahdollisesti ohittaa.

on kieliä, joissa puolipiste on todella valinnainen ja sitä käytetään harvoin. Javascriptissä on kuitenkin tapauksia, joissa rivimurtoa ei tulkita puolipisteeksi, jolloin koodi on altis virheille. Katso lisää siitä luvun Koodirakenne.

Jos olet kokenut JavaScript-ohjelmoija, voit valita puolipisteettömän koodityylin kuten StandardJS. Muuten on parasta käyttää puolipisteitä mahdollisten sudenkuoppien välttämiseksi. Suurin osa kehittäjistä laittaa puolipisteitä.

Pesintätasot

yrittävät välttää pesintäkoodia liian monta tasoa syvällä.

esimerkiksi Loopissa on joskus hyvä käyttää continue direktiiviä ylimääräisen pesinnän välttämiseksi.

esimerkiksi sen sijaan, että lisättäisiin sisäkkäinen if ehdollinen näin:

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

voimme kirjoittaa:

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

vastaava voidaan tehdä if/else ja return.

esimerkiksi kaksi alla olevaa konstruktiota ovat identtisiä.

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

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

toinen on luettavampi, koska n < 0: n”erikoistapaus”käsitellään varhaisessa vaiheessa. Kun tarkistus on tehty, voimme siirtyä ”pääkoodivirtaan” ilman lisäpesien tarvetta.

Funktiosijoitus

Jos kirjoitat useita ”auttaja” – funktioita ja niitä käyttävää koodia, on funktioiden järjestämiseen kolme tapaa.

useimmiten suositaan toista muunnosta.

Tämä johtuu siitä, että lukiessamme koodia haluamme ensin tietää, mitä se tekee. Jos koodi menee ensin, se selviää heti alusta. Sitten, ehkä meidän ei tarvitse lukea toimintoja ollenkaan, varsinkin jos niiden nimet kuvaavat, mitä he todella tekevät.

tyylioppaat

tyylioppaat sisältävät yleisiä sääntöjä ”miten kirjoitetaan” – koodista, esim.mitkä lainausmerkit käytetään, kuinka monta välilyöntiä sisennetään, maksimiviivan pituus jne. Paljon pieniä asioita.

kun kaikki joukkueen jäsenet käyttävät samaa tyyliopasta, koodi näyttää yhtenäiseltä riippumatta siitä, kuka joukkueen jäsen sen kirjoitti.

Toki joukkue voi aina kirjoittaa oman tyylioppaansa, mutta yleensä siihen ei ole tarvetta. On olemassa monia olemassa oppaita valita.

joitakin suosittuja valintoja:

• Googlen JavaScript-tyyliopas
• Airbnb JavaScript-tyyliopas
• Idiomatic.JS
• StandardJS
• (plus monta muuta)

Jos olet aloitteleva Kehittäjä, aloita lunttilapulla tämän luvun alussa. Sitten voit selata muita tyylioppaita poimia lisää ideoita ja päättää, kumpi pidät eniten.

automatisoidut Linterit

Linterit ovat työkaluja, joilla voi automaattisesti tarkistaa koodin tyylin ja tehdä parannusehdotuksia.

hienoa niissä on se, että tyylitarkistuksessa voi myös löytää joitain bugeja, kuten kirjoitusvirheitä muuttujan tai funktion nimissä. Tämän ominaisuuden vuoksi Linterin käyttäminen on suositeltavaa, vaikka et haluaisikaan pitää kiinni yhdestä tietystä ”koodityylistä”.

Tässä muutamia tunnettuja lintausvälineitä:

• JSLint-yksi ensimmäisistä lintereistä.
• JSHint – enemmän asetuksia kuin JSLint.
• ESLint – luultavasti uusin.

kaikki voivat hoitaa homman. Kirjoittaja käyttää Eslintiä.

useimmat linterit on integroitu moniin suosittuihin editoreihin: vain ottaa plugin muokkaimessa ja määrittää tyylin.

esimerkiksi Eslintille kannattaa tehdä seuraava:

1. Asenna solmu.js.
2. Asenna ESLint komennolla npm install -g eslint (npm on JavaScript-paketin asennusohjelma).
3. luo asetustiedosto .eslintrc JavaScript-projektisi juureen (kansioon, joka sisältää kaikki tiedostosi).
4. Asenna / Ota käyttöön eslintiin integroituvan muokkaimen liitännäinen. Suurimmalla osalla toimittajista sellainen on.

tässä esimerkki .eslintrc tiedosto:

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

tässä direktiivi"extends"tarkoittaa, että kokoonpano perustuu ”eslint:recommended” – asetuskokoelmaan. Sen jälkeen täsmennämme omamme.

on myös mahdollista ladata tyylisääntökokonaisuuksia verkosta ja laajentaa niitä sen sijaan. Katso http://eslint.org/docs/user-guide/getting-started lisätietoja asennuksesta.

myös eräissä IDE: issä on sisäänrakennettu lintaus, joka on kätevä mutta ei yhtä muokattavissa kuin ESLint.

Yhteenveto

kaikki tässä luvussa (ja viitatuissa tyylioppaissa) kuvatut syntaksisäännöt pyrkivät lisäämään koodin luettavuutta. Ne kaikki ovat kiistanalaisia.

kun ajattelemme ”paremman” koodin kirjoittamista, meidän tulisi kysyä itseltämme: ”mikä tekee koodista luettavamman ja helpomman ymmärtää?”ja” mikä voi auttaa meitä välttämään virheitä?”Nämä ovat tärkeimmät asiat, jotka kannattaa pitää mielessä, kun valitsee ja keskustelee koodityyleistä.

lukiessasi suosittuja tyylioppaita voit pysyä ajan tasalla uusimmista käsityksistä koodityylin trendeistä ja parhaista käytännöistä.