Keskustelu: Nettisivujen teko: Javascriptin constin, letin ja varin ero

Javasript-kurssilla sanottiin, että koskaan ei tulisi käyttää varia, vaan suosia constia ja sitten letiä. En ihan hahmottanut niiden eroa. Constia pitäisi kai käyttää useimmiten. Mutta missä tilanteissa letin käyttö on järkevää ja milloin varin? Tuntuu hassulta laittaa const vaikkapa taulukkoon, jota muutetaan myöhemmin, mutta kuulemma tämä on tapana.

Jos muuttujan arvoa tullaan muuttamaan ohjelmassa: let
Jos taas muuttujan arvo tulee olemaan aina sama: const

let counter = 0;

counter++;
counter++;

console.log(counter); // 2

const PI = 3.141; // piin arvoa ei tulla ikinä muuttamaan

PI = 3; // Ei toimi ja heittää virheen, constin arvoa ei tule muuttaa

vaikka taulukon ja objektin arvoja voi muuttaa, vaikka käyttäisi constia, niin itse käytän niitä ylemmän periaatteen mukaan

const kielet = ['Englanti', 'Suomi'];
let oppilaat = [];

oppilaat.push('Olli');
oppilaat.push('Uolevi');

Nuolifunktioissa taas käytä aina constia:

const factorial = n => {
  let fact = 1;
  for (let i = 2; i <= n; i++) {
    fact *= i;
  }

  return fact;
}

Tuo kuulostaa järkevältä, mutta ihmettelin, kun kurssilla käytettiin constia muuttuviin taulukkoihin. Ajattelin, että onko tälle joku syy, jota ei kuitenkaan kurssin tietojen perusteella kannata vielä opettaa. Mutta näyttämäsi käyttö tuntuu järkevämmältä kuin kurssilla käytetty.

Kuulin toisen perustelun. Constilla taulukko siirtyy cache-muistiin, jolloin taulukon käsittely olisi nopeampaa. Ilmeisesti constia kannattaa käyttää aina kun mahdollista.

Mitä. Saisiko tuolle nyt ihan lähdettä? Mitä tarkoitat cache muistilla nyt tässä kontekstissa? Const on siis constant. const foo = 'bar' ei voi mutatoitua siis.

Jaska kirjoitti:

Kuulin toisen perustelun. Constilla taulukko siirtyy cache-muistiin, jolloin taulukon käsittely olisi nopeampaa. Ilmeisesti constia kannattaa käyttää aina kun mahdollista.

Riippunee js-moottorista voiko tuosta olla edes tuota väitettyä nopeushyötyä - ei näytä toteutuvan ainakaan Chromella:

let bla = [3,4,5,6,7]
let jee = bla.reduce((a,b)=>a+b)

Fastest: 210222769.22 ops/s ± 0.14%

const bla = [3,4,5,6,7]
let jee = bla.reduce((a,b)=>a+b)

0,28% slower: 209642438.73 ops/s ± 0.26%

noutti kirjoitti:

Mitä. Saisiko tuolle nyt ihan lähdettä?

Se on omalla FB-sivullani. Eräs nettisivujen tekijä sanoi näin.

Mitä hän mahtaa tarkoittaa cachetuksella? Kuulostaa erittäin jännältä. Onkohan joku nyt ymmärtänyt väärin jotain?

En usko, että noilla käytännössä on nopeuseroa. Itse näkisin const määrittelyn etuna, että se estää virheitä mitä voi tulla automaattisen tyypimuunnoksen johdosta.

Esimerkiksi, jos teet kirjoitusvirheen tai aivot toimivat nopeammin kuin sormet näppäimistöllä: ;)

let point = { x:1, y:2 }
point +=2
console.log(point)

vastaan:

const point = { x:1, y:2 }
point +=2
console.log(point)

noutti kirjoitti:

Mitä. Saisiko tuolle nyt ihan lähdettä? Mitä tarkoitat cache muistilla nyt tässä kontekstissa? Const on siis constant. const foo = 'bar' ei voi mutatoitua siis.

JavaScriptin tapauksessa tämä mielestäni on väärä ajattelumalli. Const ei estä mutatoitumista vaan sijoituksen uuteen "objektiin". Luvut ja merkkijonot vaan sattuvat olemaan mutatoitumattomia tietotyyppejä JavaScriptin tapauksessa, jolloin const toimii kuin muuttujan sisältö olisi vakio.

JavaScriptin tapauksessa const on kosmeettinen parannus: koodista näkee, että tietty muuttuja ei vaihdu, ja jalskin kuvaamalla tavalla myös virheitä voi välttää. Toisaalta muuttujan sisältö (taulukko tai olio) voi kuitenkin muuttua, joten const ei auta kääntäjää missään välimuistiasiassa. JS-kääntäjä voi ihan yhtä hyvin todeta let-sanalla määritellystä arvosta, missä kohti se muuttuu vai muuttuuko ollenkaan, eli const on tarkoitettu ohjelmoijaa eikä tietokonetta varten.

Esimerkiksi C++:n tapauksessa tilanne voisi olla toinen: siinä const voi kohdistua myös esimerkiksi taulukon sisältöön, jolloin kääntäjä voi olettaa, että arvot eivät muutu edes funktiokutsujen yhteydessä. Toisaalta käytännön hyöty tästä jää usein vähäiseksi.

Jaska kirjoitti:

Mutta missä tilanteissa letin käyttö on järkevää ja milloin varin?

Nykyään ei var-sanaa suosita. Se oli JS:n aikaisempi tapa muuttujan määrittelyyn. Se kuitenkin rikkoo yleistä käytäntöä näkyvyysalueista: var-sanalla muuttuja tulee näkyviin koko funktiossa, kun taas let-sana rajoittaa näkyvyyden nykyisiin aaltosulkuihin. Seuraava koodi havainnollistaa eroa:

function f() {
  if (true) {
    var z = 1;
    let w = 2;
  }
  console.log(z); // 1
  console.log(w); // ReferenceError: w is not defined
}

jalski kirjoitti:

(10.10.2020 09:54:33): ”– –” JavaScriptin tapauksessa tämä mielestäni on...

Tätä siis yritin tarkoittaa epäselvällä viestilläni :D Olin jostain syystä tohkeissani ensimmäistä kertaa vuosiin ohjelmointiin liittyvissä jutuissa!

Jaska kirjoitti:

Mutta missä tilanteissa letin käyttö on järkevää ja milloin varin?

letin käyttö on järkevää jos haluat välttää typeriä virheitä ja varin käyttö on järkevää kun jostain syystä koodin on pakko toimia ikivanhalla* selaimella joka ei ymmärrä letiä.

*Devaajien maailmassa 2016 on ikivanha :D

Let-tuki:
FF alkaen v44 (27.1.2016)
Chrome osittain alkaen 41 (5.3.2015) täysi alkaen 49 (3.3.2016)
IE/Edge osittain alkaen 11 (17.10.2013) täysi alkaen (29.7.2015)

Käytännössä voi toki ajatella että on parempi olla tukematta vanhoja selaimia, koska päivittämätön selain on joka tapauksessa tietoturvariski sen käyttäjälle.

Grez kirjoitti:

(10.10.2020 10:45:26): ”– –” letin käyttö on järkevää jos haluat välttää...

Jep, mutta silloin kun teet tuotetta jonka pitää toimia Raksa-penan windows ME:llä ja IE:llä niin täytyy lähestyä asiaa käyttäjäkohtaisesti. Varsinkin jos on kriittinen appis prosessin kannalta. Vaikka se pahaa tekisikin ja yleensä tekee :D

Jos on pakko tukea vanhoja selaimia, kannattaa ehkä käyttää jotain työkalua, joka kääntää modernin koodin yhteensopivaksi, niin ei tarvitse itse miettiä asiaa. Käsin tehdessä helposti käy niin, että jossain vaiheessa se yhteensopivuus unohtuu ja tulee tehtyä koodiin jokin osa, joka ei toimikaan kaikilla.

Metabolix kirjoitti:

(10.10.2020 22:15:43): Jos on pakko tukea vanhoja selaimia, kannattaa...

Juuri näin ja lisäisin perusteluksi, että kun lopulta voidaan luopua vanhan selaimen tuesta niin kas - nykyaikaiset APIt ovat jo käytössä koodissasi. JavaScriptin tapauksessa varmaan käytettäisiin ns. polyfillejä (APIen kanssa siis, ja kielen rakenteet olisi hoidettava varmaan jollain transpilerilla).

Constin käyttö ehkäisee ehkä sellaisia alkeellisia virheitä, missä muuttuja unohdetaan esitellä lohkon sisällä, jolloin vahingossa muutetaan ulommassa lohkossa esiteltyä samannimistä muuttujaa.

Itse olen ottanut käyttöön sellaisen tyylisäännöstön, jonka mukaan koodissa kaikki read-only-muuttujat ovat consteja. En niinkään minkään agendan vuoksi vaan koska se vaikutti olevan yleisessä käytössä. (Kuten on moni muu täysin erilainen säännöstökin.)

let foo = 'foo'

for (let i = 0; i < 100; i++) {
  let fo = 'fo'

  if (i % 5 === 0) {
    foo = 'bar'
  }
}

function test () {
  foo = 'asdda'
}

test()

console.log(foo)