JavaScript-tyylin elementit

Ei sinisestä - Iñaki Bolumburu (CC BY-NC-ND 2.0)
Huomaa: Tämä viesti on nyt osa ”Composing Software” -kirjaa.

Vuonna 1920 julkaistiin William Strunk Jr., ”Elements of Style”, joka asetti suuntaviivat englanninkieliselle tyylille, joka on kestänyt ajan kokeen. Voit parantaa koodiasi soveltamalla samanlaisia ​​standardeja koodityyliisi.

Seuraavat ovat ohjeita, eivät muuttumattomia lakeja. Niistä poikkeamiseen voi olla perusteltuja syitä, jos se selventää koodin merkitystä, mutta ole valppaana ja itsevarma. Nämä ohjeet ovat kestäneet aikatestauksen syystä: He ovat yleensä oikeassa. Poikkea heistä vain syystä - ei pelkästään mielivallan tai henkilökohtaisen tyylin mukaan.

Lähes kaikki sävellyksen perusperiaatteiden ohjeet koskevat lähdekoodia:

  • Tee kappale kappaleesta sävellysyksikkö: Yksi kappale jokaiselle aiheelle.
  • Älä jätä tarpeettomia sanoja.
  • Käytä aktiivista ääntä.
  • Vältä löysien lauseiden peräkkäisiä kertoja.
  • Pidä liittyvät sanat yhdessä.
  • Lause lausunnot positiivisessa muodossa.
  • Käytä samansuuntaista rakennetta rinnakkaisissa käsitteissä.

Voimme soveltaa lähes identtisiä käsitteitä koodityyliin:

  1. Tee funktiosta koostumuksen yksikkö. Yksi työ kullekin toiminnolle.
  2. Ohita turha koodi.
  3. Käytä aktiivista ääntä.
  4. Vältä löysien lausuntojen peräkkäisiä kertoja.
  5. Pidä liittyvä koodi yhdessä.
  6. Pane lausunnot ja lausekkeet positiiviseen muotoon.
  7. Käytä rinnakkaiskoodia rinnakkaiskonsepteihin.

1. Muuta toiminto koostumuksen yksiköksi. Yksi työ kullekin toiminnolle.

Ohjelmistokehityksen ydin on sävellys. Rakennamme ohjelmistoja luomalla moduulit, toiminnot ja tietorakenteet yhdessä.
Toimintojen kirjoittamisen ja säveltämisen ymmärtäminen on ohjelmistokehittäjien perusedellytys.

Moduulit ovat yksinkertaisesti kokoelmia yhdestä tai useammasta funktiosta tai tietorakenteesta, ja tietorakenteet edustavat sitä, miten edustamme ohjelman tilaa, mutta mitään mielenkiintoista ei tapahdu ennen kuin käytämme funktiota.

JavaScript-ohjelmassa on kolmen tyyppisiä toimintoja:

  • Kommunikointitoiminnot: Toiminnot, jotka suorittavat I / O.
  • Menettelytoiminnot: Luettelo ohjeista, ryhmiteltynä.
  • Kartoitustoiminnot: Jos haluat jonkin tulon, palauta vastaava lähtö.

Vaikka kaikki hyödylliset ohjelmat tarvitsevat I / O: ta, ja monet ohjelmat seuraavat joitain proseduurijärjestyksiä, suurimman osan toiminnoista tulisi olla kartoitusfunktioita: Kun otetaan huomioon jokin syöttö, funktio tuottaa vastaavan tulosteen.

Yksi asia jokaiselle toiminnolle: Jos toimintosi on I / O, älä sekoita sitä I / O kartoitukseen (laskenta). Jos toimintosi on kartoitus, älä sekoita sitä I / O: n kanssa. Menettelytoiminnot rikkovat määritelmänsä mukaan tätä suuntaviivaa. Proseduuritoiminnot rikkovat myös toista ohjeistoa: Vältä peräkkäisiä löysät lausunnot.

Ihanteellinen toiminto on yksinkertainen, deterministinen, puhdas funktio:

  • Samaa tuloa käytettäessä palauta aina sama lähtö
  • Ei sivuvaikutuksia

Katso myös, "Mikä on puhdas toiminto?"

2. Poista tarpeeton koodi.

”Voimakas kirjoittaminen on tiivistä. Lauseessa ei saa olla tarpeettomia sanoja, kappaleessa ei saa olla tarpeettomia lauseita samasta syystä, että piirustuksessa ei tulisi olla tarpeettomia viivoja ja koneessa ei olisi tarpeettomia osia. Tämä ei edellytä, että kirjoittaja tee kaikki lauseet lyhyiksi tai välttää kaikki yksityiskohdat ja käsittelee aiheita vain ääriviivoissa, vaan että jokainen sana kertoo. ”[Tarpeettomat sanat jätetään pois.]
~ William Strunk, Jr, tyylin elementit

Tiivis koodi on kriittinen ohjelmistossa, koska enemmän koodia luo enemmän pinta-aluetta piilottaville virheille. Vähemmän koodia = vähemmän paikkoja virheille piilottamiseen = vähemmän virheitä.

Tiivis koodi on selkeämpi, koska sillä on korkeampi signaali-kohinasuhde: Lukijan on seulottava vähemmän syntaksimelu melun saavuttamiseksi. Vähemmän koodia = vähemmän syntaksikohinaa = voimakkaampi signaali tarkoitusta varten.

Lainataksesi sana Elements of Style: Tiivis koodi on voimakkaampi.

toiminnon salaisuus (viesti) {
  paluutoiminto () {
    palautusviesti;
  }
};

Voidaan supistaa:

const secret = msg => () => msg;

Tämä on paljon luettavissa niille, jotka tuntevat tiiviin nuolen toiminnot (otettiin käyttöön vuonna 2015 ES6: lla). Se jättää tarpeettoman syntaksin pois: Pidikkeet, toimintoavainsanat ja paluulausekkeen.

Ensimmäinen sisältää tarpeettoman syntaksin. Pidikkeet, funktio-avainsana ja paluulausunto eivät ole tarkoituksenmukaisia ​​niille, jotka tuntevat tiiviin nuolen syntaksin. Se on olemassa vain, jotta koodi saadaan tutuksi niille, jotka eivät vielä suju ES6: n kanssa.

ES6 on ollut kielen standardi vuodesta 2015. On aika tutustua.

Ohita turhat muuttujat

Joskus meillä on houkutus antaa nimiä asioille, joita ei oikeastaan ​​tarvitse nimetä. Ongelmana on, että ihmisen aivoilla on rajoitettu määrä resursseja käytettävissä työmuistissa ja jokainen muuttuja on tallennettava erillisenä kvanttina, käytettäessä yhtä käytettävissä olevista työmuistipaikoista.

Tästä syystä kokeneet kehittäjät oppivat poistamaan muuttujia, joita ei tarvitse olla olemassa.

Esimerkiksi, useimmissa tilanteissa sinun tulisi jättää pois muuttujat, jotka on luotu vain paluuarvojen nimeämiseksi. Toimintosi nimen tulisi antaa riittävät tiedot siitä, mitä toiminto palaa. Harkitse seuraavaa:

const getFullName = ({firstName, lastName}) => {
  const fullName = etunimi + '' + sukunimi;
  return fullName;
};

vs ...

const getFullName = ({firstName, lastName}) => (
  etunimi + '' + sukunimi
);

Toinen yleinen tapa, jolla kehittäjät voivat vähentää muuttujia, on käyttää hyväksi toimintojen koostumus ja pisteettömä tyyli.

Pisteettömä tyyli on tapa määritellä funktiot viittamatta argumentteihin, joilla funktiot toimivat. Yleisiä tapoja saavuttaa pisteettömä tyyli ovat curryminen ja funktion koostumus.

Katsotaanpa esimerkkiä currya käyttämällä:

const add2 = a => b => a + b;
// Nyt voimme määritellä pisteettömän inc ()
//, joka lisää 1 mihin tahansa numeroon.
const inc = add2 (1);
inc (3); // 4

Katsokaa inc () -funktion määritelmää. Huomaa, että siinä ei käytetä funktion avainsanaa tai => syntaksia. Parametreja ei ole paikalla luetteloida, koska toiminto ei käytä parametriluetteloa sisäisesti. Sen sijaan se palauttaa toiminnon, joka osaa käsitellä argumentteja.

Katsotaanpa toista esimerkkiä funktion koostumuksen avulla. Funktion koostumus on prosessi, jossa funktio kohdistetaan toisen funktion sovelluksen tulokseen. Käytätkö toimintokoostumusta jatkuvasti riippumatta siitä, huomaatko sen tai ei. Käytät sitä aina ketjuttamalla menetelmiä, kuten .map () tai luba.then (). Alkeisimmassa muodossaan se näyttää tältä: f (g (x)). Algebrassa tämä koostumus kirjoitetaan yleensä f ∘ g (lausutaan usein sanalla “f g: n jälkeen” tai “f koostuu g: llä”).

Kun sävelet kaksi toimintoa yhdessä, sinun ei tarvitse luoda muuttujaa väliarvon pitämiseksi kahden funktiosovelluksen välillä. Katsotaanpa kuinka funktion koostumus voi puhdistaa koodin:

const g = n => n + 1;
const f = n => n * 2;
// pisteillä:
const incThenDoublePoints = n => {
  const lisätty = g (n);
  paluu f (lisätty);
};
incThenDoublePoints (20); // 42
// compose2 - Ota kaksi toimintoa ja palauta niiden koostumus
const compose2 = (f, g) => x => f (g (x));
// Ilmainen:
const incThenDoublePointFree = compose2 (f, g);
incThenDoublePointFree (20); // 42

Voit tehdä saman asian millä tahansa functorilla. Toiminto on mikä tahansa, jonka voit kartoittaa, esim. Taulukot (Array.map ()) tai lupaukset (luby.then ()). Kirjoitamme toisen version compose2: sta käyttämällä karttaketjua funktion koostumukseen:

const compose2 = (f, g) => x => [x] .map (g) .map (f) .pop ();
const incThenDoublePointFree = compose2 (f, g);
incThenDoublePointFree (20); // 42

Teet paljon samaa asiaa joka kerta kun käytät lupausketjuja.

Lähes jokaisessa toiminnallisessa ohjelmointikirjastossa on vähintään kaksi versiota kirjoitusapuohjelmista: compose (), joka käyttää toimintoja oikealta vasemmalle, ja pipe (), joka käyttää toimintoja vasemmalta oikealle.

Lodash kutsuu heitä säveltämään () ja virtaamaan (). Kun käytän niitä Lodashista, tuon sen aina näin:

tuontiputki tuotteesta 'lodash / fp / flow';
putki (g, f) (20); // 42

Tämä ei kuitenkaan ole paljon enemmän koodi, ja se tekee saman asian:

const pipe = (... fns) => x => fns.reduce ((acc, fn) => fn (acc), x);
putki (g, f) (20); // 42

Jos tämä funktiokoostumuksen juttu kuulostaa sinulle vieraalta, etkä ole varma, kuinka käytit sitä, harkitse tätä huolellisesti:

Ohjelmistokehityksen ydin on sävellys. Rakennamme sovelluksia luomalla pienempiä moduuleja, toimintoja ja tietorakenteita.

Tästä voidaan päätellä, että toiminnan ja esineiden koostumuksen työkalujen ymmärtäminen on yhtä tärkeää kuin kodinvalmistaja, joka ymmärtää porat ja naula-aseet.

Kun käytät pakollista koodia toimintojen yhdistämiseen välimuuttujien kanssa, se on kuin näiden kappaleiden säveltäminen kanavateipillä ja hulluilla liimoilla.

Muistaa:

  • Jos voit sanoa saman asian vähemmän koodilla, muuttamatta tai hämärtämättä merkitystä, sinun pitäisi.
  • Jos pystyt sanomaan saman asian vähemmällä muuttujalla muuttamatta tai hämärtämättä merkitystä, sinun pitäisi.

3. Käytä aktiivista ääntä

”Aktiivinen ääni on yleensä suorampaa ja voimakkaampaa kuin passiivinen.” ~ William Strunk, Jr, tyylin elementit

Nimeä asiat mahdollisimman suoraan.

  • myFunction.wasCalled () on parempi kuin myFunction.hasBeenCalled ()
  • createUser () on parempi kuin User.create ()
  • ilmoita () on parempi kuin Notifier.doNotification ()

Nimeä predikaatit ja booleat ikään kuin ne olisivat kyllä ​​tai ei:

  • isActive (käyttäjä) on parempi kuin getActiveStatus (käyttäjä)
  • isFirstRun = false; on parempi kuin firstRun = false;

Nimeä funktiot verbimuotojen avulla:

  • lisäys () on parempi kuin plusOne ()
  • unzip () on parempi kuin filesFromZip ()
  • suodatin (fn, array) on parempi kuin matchingItemsFromArray (fn, array)

Tapahtumien käsittelijät

Tapahtumien käsittelijät ja elinkaarimenetelmät ovat poikkeus verbisäännöstä, koska niitä käytetään tarkentajina; sen sijaan, että ilmaisivat mitä tehdä, he ilmaisevat milloin tehdä sen. Ne tulisi nimetä niin, että he lukevat ”, ”.

  • element.onClick (handleClick) on parempi kuin element.click (handleClick)
  • komponentti.onDragStart (handleDragStart) on parempi kuin komponentti.startDrag (handleDragStart)

Toisessa muodossa näyttää siltä, ​​että yritämme laukaista tapahtuman sen sijaan, että reagoisimme siihen.

Elinkaarimenetelmät

Harkitse seuraavia vaihtoehtoja komponentin hypoteettiselle elinkaarimenetelmälle, joka on olemassa, jotta kutsutaan käsittelijäfunktiota ennen komponentin päivityksiä:

  • componentWillBeUpdated (doSomething)
  • componentWillUpdate (doSomething)
  • beforeUpdate (doSomething)

Ensimmäisessä esimerkissä käytämme passiivista ääntä (päivitetään päivityksen sijaan). Se on suurta, eikä yhtään selkeämpää kuin muut vaihtoehdot.

Toinen esimerkki on paljon parempi, mutta tämän elinkaaren menetelmän koko tarkoitus on kutsua käsittelijä. komponenttiWillUpdate (käsittelijä) lukee ikään kuin se päivittää käsittelijän, mutta sitä ei tarkoiteta. Tarkoitamme, “ennen komponentin päivityksiä, soita käsittelijälle”. beforeComponentUpdate () ilmaisee aikomuksen selkeämmin.

Voimme yksinkertaistaa entisestään. Koska nämä ovat menetelmiä, aihe (komponentti) on sisäänrakennettu. Viittaus siihen menetelmän nimessä on tarpeetonta. Ajattele, miten se lukea, jos kutsuisit näitä menetelmiä suoraan: komponent.componentWillUpdate (). Se on kuin sanominen: “Jimmy Jimmy saa pihvin illalliselle.” Sinun ei tarvitse kuulla kohteen nimeä kahdesti.

  • komponentti.ennakko päivitys (doSomething) on ​​parempi kuin komponentti.ennakko komponenttipäivitys (doSomething)

Funktionaaliset sekoitukset ovat toimintoja, jotka lisäävät ominaisuuksia ja menetelmiä objektiin. Toiminnot otetaan käyttöön peräkkäin putkilinjassa - kuten kokoonpanolinja. Jokainen toiminnallinen sekoitus ottaa esiintymän syötteenä ja tarttuu siihen joitain asioita ennen siirtämistä seuraavaan toimintoon putkilinjassa.

Tykkään nimetä funktionaalisia sekoituksia adjektiivien avulla. Voit käyttää hyödyllisiä adjektiiveja usein “ing” tai “pystyttävä” -liitteillä. esimerkkejä:

  • const ankka = säveltäMiksiinit (lentävät, järkyttävät);
  • const-ruutu = composeMixins (toistettavissa, kartoitettavissa);

4. Vältä löysien lausumien peräkkäisiä kertoja

"... sarjasta tulee pian yksitoikkoinen ja tylsiä."
~ William Strunk, Jr, tyylin elementit

Kehittäjät nauhoittavat usein tapahtumien sekvenssit proseduurissa: ryhmä löysästi liittyviä lauseita, jotka on suunniteltu toimimaan peräkkäin. Ylimääräinen menettelytapa on resepti spagettikoodille.

Sellaiset sekvenssit toistuvat usein monilla rinnakkaisilla muodoilla, kukin niistä hienovaraisesti ja toisinaan odottamatta erottelemalla. Esimerkiksi käyttöliittymäkomponentilla on samat ydintarpeet käytännössä kaikkien muiden käyttöliittymäkomponenttien kanssa. Sen huolet voidaan jakaa elinkaarivaiheisiin ja hallita erillisillä toiminnoilla.

Harkitse seuraavaa järjestystä:

const drawUserProfile = ({userId}) => {
  const userData = loadUserData (userId);
  const dataToDisplay = calcDisplayData (userData);
  renderProfileData (dataToDisplay);
};

Tämä toiminto käsittelee todella kolmea eri asiaa: datan lataaminen, näkymän tilan laskeminen ladatusta tiedosta ja renderointi.

Useimmissa moderneissa käyttöliittymäsovellusarkkitehtuureissa kutakin näistä huolenaiheista tarkastellaan erikseen. Erottamalla nämä huolenaiheet voimme helposti sekoittaa ja sovittaa eri toiminnot kullekin huolenaiheelle.

Voisimme esimerkiksi korvata renderoijan kokonaan, eikä se vaikuta ohjelman muihin osiin, esimerkiksi Reaktin mukautettujen renderoijien runsauteen: ReactNative natiivien iOS- ja Android-sovellusten kohdalla, AFrame WebVR: lle, ReactDOM / Server palvelinpuolen renderoinnille. , jne…

Toinen tämän toiminnon ongelma on, että et voi yksinkertaisesti laskea näytettäviä tietoja ja luoda merkinnät lataamatta ensin tietoja. Entä jos olet jo ladannut tiedot? Loppujen lopuksi teet töitä, joita sinun ei tarvitse tehdä seuraavissa puheluissa.

Huolenaiheiden erottaminen tekee niistä myös itsenäisesti testattavissa. Haluan testata sovelluksiani ja näyttää testitulokset jokaisen muutoksen yhteydessä kirjoittaessani koodia. Jos kuitenkin sitoudutaan renderointikoodiin tietojen latauskoodiin, en voi yksinkertaisesti välittää vääriä tietoja renderöintikoodiin testausta varten. Minun on testattava koko komponentti päästä päähän - prosessi, joka voi olla aikaa vievä selaimen lataamisen, asynkronisen verkon I / O: n jne. Vuoksi ...

En saa välitöntä palautetta yksikkötestistäni. Toimintojen erottaminen antaa sinun testata yksiköitä erillään toisistaan.

Tässä esimerkissä on jo erilliset toiminnot, joita voimme syöttää sovelluksen erilaisiin elinkaarikoukkuihin. Lataus voidaan laukaista, kun sovellus asentaa komponentin. Laskeminen ja renderointi voi tapahtua vastauksena tilapäivityksiin.

Tuloksena on ohjelmisto, jonka vastuut on määritelty selkeämmin: Jokainen komponentti voi käyttää uudelleen samaa rakennetta ja elinkaarikoukkuja, ja ohjelmisto toimii paremmin; emme toista työtä, jota ei tarvitse toistaa seuraavissa jaksoissa.

5. Pidä liittyvä koodi yhdessä.

Monet kehykset ja kattilalevyt määräävät ohjelman organisointimenetelmän, jossa tiedostot on ryhmitelty teknisen tyypin mukaan. Tämä on hienoa, jos rakennat pientä laskinta tai Tehtäväsovellusta, mutta suurempien projektien kohdalla on yleensä parempi ryhmitellä tiedostot ominaisuuksien mukaan.

Tässä on esimerkiksi kaksi vaihtoehtoista tiedostohierarkiaa tehtäväsovellukselle tyypin ja ominaisuuden mukaan:

Ryhmitelty tyypin mukaan:

.
├── komponentit
Dos ├── todos
│ └── käyttäjä
├── supistimet
Dos ├── todos
│ └── käyttäjä
└── testit
    ├── todos
    └── käyttäjä

Ryhmitelty ominaisuuden mukaan:

.
├── todos
│ ├── komponentti
│ ├── vähennysventtiili
│ └── testi
└── käyttäjä
    ├── komponentti
    ├── vähennysventtiili
    └── testi

Kun ryhmität tiedostoja ominaisuuksien mukaan, vältät vierittämistä tiedostoluettelossa ylös ja alas löytääksesi kaikki muokattavat tiedostot saadaksesi yhden ominaisuuden toimimaan.

Yhdistä ominaisuuksiin liittyvät tiedostot.

6. Pane lausunnot ja lausekkeet positiiviseen muotoon.

”Tee selvät väitteet. Vältä kesyttää, väritöntä, epäröivää ja sitoutumatonta kieltä. Älä käytä sanaa kieltämisen välineenä tai vastalauseena, älä koskaan veronkierron välineenä. "
~ William Strunk, Jr, tyylin elementit
  • isFlying on parempi kuin isNotFlying
  • myöhässä on parempi kuin notOnTime

Jos lausunnot

if (virhe) paluu hylätä (virhe);
// tee jotain...

…on parempi kuin:

jos (! virhe) {
  // ... tee jotain
} muuta {
  paluu hylätä (virhe);
}

Ternaries

{
  [Symbol.iterator]: iteraattori? iteraattori: defaultIterator
}

…on parempi kuin:

{
  [Symbol.iterator]: (! Iteraattori)? defaultIterator: iteraattori
}

Suosittele vahvoja kielteisiä lausumia

Joskus välitämme muuttujasta vain, jos se puuttuu, joten positiivisen nimen käyttäminen pakottaisi meidät kumoamaan sen muuttujalla! operaattori. Valitse näissä tapauksissa vahva negatiivinen muoto. Sana "ei" ja! operaattori luo heikkoja lausekkeita.

  • if (missingValue) on parempi kuin if (! hasValue)
  • if (tuntematon) on parempi kuin if (! user)
  • if (isEmpty (asia)) on parempi kuin if (notDefined (asia))

Vältä tyhjiä ja määrittelemättömiä argumentteja funktiokutsuissa

Älä vaadi toiminto soittajia siirtämään määrittelemätöntä tai nollaa valinnaisen parametrin sijasta. Suosittele sen sijaan nimettyjä vaihtoehtoobjekteja:

const createEvent = ({
  otsikko = 'otsikko',
  timeStamp = Date.now (),
  kuvaus = ''
}) => ({otsikko, kuvaus, timeStamp});
// myöhemmin ...
const birthdayParty = createEvent ({
  otsikko: "Syntymäpäiväjuhlat",
  kuvaus: 'Paras juhla!'
});

…on parempi kuin:

const createEvent = (
  otsikko = 'otsikko',
  timeStamp = Date.now (),
  kuvaus = ''
) => ({otsikko, kuvaus, timeStamp});
// myöhemmin ...
const birthdayParty = createEvent (
  'Syntymäpäiväjuhlat',
  määrittelemätön, // Tämä oli vältettävissä
  'Parhaat bileet ikinä!'
);

Käytä rinnakkaiskoodia rinnakkaiskonsepteihin

”… Rinnakkainen rakentaminen edellyttää, että samanlaisen sisällön ja toiminnan ilmaisujen on oltava ulkoisesti samanlaisia. Muodon samankaltaisuus antaa lukijalle tunnistaa helpommin sisällön ja toiminnan samankaltaisuuden. "
~ William Strunk, Jr, tyylin elementit

Sovelluksissa on vähän ongelmia, joita ei ole aiemmin ratkaistu. Loppujen lopuksi teemme samat asiat uudestaan ​​ja uudestaan. Kun se tapahtuu, se on tilaisuus abstraktioon. Tunnista samat osat ja rakenna abstraktio, jonka avulla voit toimittaa vain erilaisia ​​osia. Juuri nämä kirjastot ja kehykset tekevät meille.

Käyttöliittymäkomponentit ovat loistava esimerkki. Alle kymmenen vuotta sitten oli yleistä sekoittaa käyttöliittymäpäivityksiä jQueryllä sovelluslogiikan ja verkko I / O: n avulla. Sitten ihmiset alkoivat ymmärtää, että voimme soveltaa MVC: tä verkkosovelluksiin asiakaspuolella, ja ihmiset alkoivat erottaa malleja käyttöliittymän päivityslogiikasta.

Lopulta verkkosovellukset laskivat komponenttimallilähestymistavan, jonka avulla voimme mallinntaa komponenttejamme deklaratiivisesti käyttämällä esimerkiksi JSX- tai HTML-malleja.

Se mitä päädyimme on tapa ilmaista käyttöliittymän päivityslogiikka samalla tavalla jokaiselle komponentille kuin eri pakollinen koodi jokaiselle.

Komponenteille perehtyneille on melko helppo nähdä, kuinka kukin komponentti toimii: On olemassa joitain deklaratiivisia merkintöjä, jotka ilmaisevat käyttöliittymän elementit, tapahtumakäsittelijät käyttäytymisen kytkemiseen ja elinkaarikoukut takaisinsoittojen liittämiseen, jotka alkavat, kun tarvitsemme niitä.

Kun toistamme samanlaisen kuvion samanlaisille ongelmille, kenen tahansa perehtyneen pitäisi voida oppia nopeasti koodin toiminta.

Päätelmä: Koodin tulisi olla yksinkertainen, ei yksinkertainen

Voimakas kirjoittaminen on tiivistä. Lauseessa ei saa olla tarpeettomia sanoja, kappaleessa ei saa olla tarpeettomia lauseita samasta syystä, että piirustuksessa ei tulisi olla tarpeettomia viivoja ja koneessa ei olisi tarpeettomia osia. Tämä ei edellytä, että kirjoittaja tee kaikki lauseet lyhyiksi tai välttää kaikki yksityiskohdat ja käsittelee aiheita vain ääriviivat, vaan että jokainen sana kertoo. [Painotus lisätty.]
~ William Strunk, Jr, tyylin elementit

ES6 standardoitiin vuonna 2015, mutta vuonna 2017 monet kehittäjät välttävät ominaisuuksia, kuten tiiviin nuolen toimintoja, implisiittisiä palautus-, lepo- ja leviämisoperaattoreita jne. ... koodin kirjoittamisen varjolla, jota on helpompi lukea, koska se on tutumpi. Se on iso virhe. Tunnettavuus liittyy käytännössä, ja perehtyneisyydessä ES6: n tiiviit piirteet ovat selvästi parempia kuin ES5-vaihtoehdot: tiivis koodi on yksinkertainen verrattuna syntaksin raskaaseen vaihtoehtoon.

Koodin tulisi olla yksinkertainen, ei yksinkertaista.

Koska tiivis koodi on:

  • Vähemmän vikoja
  • Helppo virheenkorjaus

Ja ottaen huomioon nämä virheet:

  • Ovat erittäin kalliita korjata
  • Aiheuttaa lisää virheitä
  • Keskeytä ominaisuuden normaalin kehityksen kulku

Ja ottaen huomioon, että tiivis koodi on myös:

  • Helpoin kirjoittaa
  • Helppo lukea
  • Helppo ylläpitää

Koulutusinvestoinnin arvoinen on tuoda kehittäjät nopeuteen käyttämällä tekniikoita, kuten tiivistä syntaksia, curryausta ja sävellystä. Kun emme tee niin perehtymisen vuoksi, puhumme koodimme lukijoille, jotta he ymmärtävät sitä paremmin, kuten aikuisen puhuva vauvapuhe taaperoille.

Oletetaan, että lukija ei tiedä mitään toteutuksesta, mutta älä oleta, että lukija on tyhmä tai että lukija ei osaa kieltä.

Ole selkeä, mutta älä tukahduta sitä. Asioiden tyhjentäminen on tuhlaa ja loukkaavaa. Tee sijoitus käytännössä ja perehtyneisyys paremman ohjelmasanaston ja voimakkaamman tyylin saamiseksi.

Koodin tulisi olla yksinkertainen, ei yksinkertaista.

Tasoita taitojasi live-ohjauksella 1: 1

DevAnywhere on nopein tapa tasoittaa edistyneitä JavaScript-taitoja:

  • Live-oppitunnit
  • Joustavat tunnit
  • 1: 1 mentorointi
  • Luo todellisia tuotantosovelluksia
https://devanywhere.io/

Eric Elliott on kirjoittanut ”Programming JavaScript Applications” -sovelluksen (O’Reilly) ja on DevAnywhere.io: n perustaja. Hän on osallistunut ohjelmistokokemuksiin Adobe Systemsille, Zumba Fitnessille, The Wall Street Journalille, ESPN: lle, BBC: lle ja parhaimmille äänittäjille, kuten Usher, Frank Ocean, Metallica ja monille muille.

Hän työskentelee missä vain haluaa, maailman kauneimman naisen kanssa.