Zmienne const zamiast normalnych

Dlaczego w większości zakładów pracy przy pisaniu w JavaScripcie jest teraz obowiązek używania const do deklarowania zmiennych?

Na przykład:

const dataToSend = {};
// ...
dataToSend.jakiśKlucz = jakaśWartość;

Dla mnie używanie const zamiast normalnego let do czegoś innego niż prawdziwe stałe (uniwersalne jak liczba pi czy lokalne dla aplikacji jak np. wpisana na stałe w kodzie szybkość animacji) jest szokujące, ale tak robię, bo za dłuższe kłócenie się o to straciłbym pracę.

Umieszczam pytanie tu, ale może dział JavaScript byłby lepszy. Chociaż nie mam problemu z technologią, tylko z tym co ludzie z nią robią.

Zmiana wartości stałej nie jest dozwolona i myślę, że nie wiesz o co się kłócisz i inni jednak mają rację.

Const to nie zmienne tylko jak sama nazwa wskazuje STAŁE.
Natomiast let od var różnią się zasięgiem
Często do const przypisuje się NA STAŁE jakiś obiekt, którego właściwości wciąż można modyfikować i nie oznacza to, że const staje się zmienną a jedynie tyle, że JavaScript trzyma w tej stałej jedynie referencję do obiektu.

Zmiana wartości stałej nie jest dozwolona:

    const a = 7;
    console.log (a);
    a = a + 1;
    console.log (a);

Zwróci błąd:

buttons.html:15 Uncaught TypeError: Assignment to constant variable. at buttons.html:3:7

Zupełnie czymś innym jest:

    const a = {
      "property1":1,
      "property2":2,
    }
    console.log (a);    
    a.property1 = 2 ;    
    console.log (a);

Zmiana właściwości obiektu jest jak najbardziej dozwolona!
Nie wolno natomiast wciąż zmieniać wartośći a, które jest STAŁĄ.

    const a = {
      "property1":1,
      "property2":2,
    }
    console.log (a);    
    a = {} ;    
    console.log (a);   

Powyższe zwróci błąd:

buttons.html:18 Uncaught TypeError: Assignment to constant variable.

Dlaczego w Javie wszyscy piszą final?
Twój przykład jest zły, const do typu obiektowego, działa tylko dla ponownego przypisania nie obiektu w środku. Wiec klucze możesz dodawać sobie jak chcesz.(poczytaj jak to działa)
const powoduje że nie możesz zmienić jej typu, spróbuj teraz do tej zmiennej dataToSend przypisać stringa, co się stanie?

Pierwsza odpowiedź idealnie pokazuje o co tu chodzi:
https://stackoverflow.com/questions/41086633/why-most-of-the-time-should-i-use-const-instead-of-let-in-javascript

Chodzi o to, żeby częściej były komunikaty o błędach (komunikaty są dobre, bo pokazują, że coś może być nie tak).

Jak zrobisz const, to jak będziesz chciał przypisać coś na nowo niechcący, to ci się pokaże błąd. Dlatego właśnie to jest spoko, że chroni przed takimi sytuacjami. Co prawda const jest o tyle słaby w JS, że dalej można mutować obiekty w ten sposób, ale przynajmniej dla prymitywów to działa dobrze. Tym niemniej nawet w przypadku obiektów dobrze mieć zabezpieczenie przed tym, że przypadkowo je nadpiszesz nową referencją wtedy, kiedy nie powinieneś.

Ogólne odpowiedzi są następujące.

1. Dlaczego w większości zakładów pracy przy pisaniu w JavaScripcie jest teraz obowiązek używania const do deklarowania zmiennych?

   Bo są tak cienkimi programistami nie znającymi podstaw, że nawet nie odróżniają zmiennej od stałej.

2. Dlaczego w Javie wszyscy piszą final?

   Bo są tak cienkimi programistami nie znającymi podstaw, że nawet nie odróżniają zmiennych od właściwości klasy.

A najlepsze jest to, że to podstawy i wystarczy zerknąć do pierwszej lepszej dokumentacji JS znalezionej w sieci i przejrzeć gotowe przykłady:

https://docs.onux.com/en-US/Developers/JavaScript-PP/Language/Reference/Modifiers/final

katakrowa napisał(a):

Ogólne odpowiedzi są następujące.

2. Dlaczego w Javie wszyscy piszą final?

   Bo są tak cienkimi programistami nie znającymi podstaw, że nawet nie odróżniają zmiennych od właściwości klasy.

Powiedziałbym że:
Dlaczego wszyscy zadaja pytania o final
Bo ... itd ...

Jeśli w jakimś języku trzeba ciągle pisać jakieś 5 literowe słowo kluczowe, to może ten język po prostu jest źle zaprojektowany. Jeśli wszyscy piszą final, to może właśnie final powinno być domyślne i implicite jak się nie napisze inaczej?

@valdemar właściwie to już w wątku zostało powiedziane, ale myślę, że można to ując innymi słowami.

const w js sprawia, że Twoja referencja jest stała. Nie możesz jej przepiąć.

Myślę, że słowo const miało na celu nawiązanie do C++, w którym za pomocą const możesz oznaczyć nie tylko wskazywany obiekt, ale sam wskaźnik.

const Foo * const foo = new Foo(); 

LukeJL napisał(a):

Jeśli w jakimś języku trzeba ciągle pisać jakieś 5 literowe słowo kluczowe, to może ten język po prostu jest źle zaprojektowany. Jeśli wszyscy piszą final, to może właśnie final powinno być domyślne i implicite jak się nie napisze inaczej?

Hmmm ... dla mnie nie jest to problemem.
Odwrotne próby (tj "pisz gdy nie-final") nie są (znacząco) lepsze.

Dla mnie dyskomfortem jest w Javie rozbicie na typy elementarne i obiektowe, ale to było/jest ważne ze wzg wydajnościowych, jakby najgłupszy integer był pełnoprawnym obiektem (a tablica integrerów tablicą obiektów), to szybkość by siadła.

Ciekawe problem rozwiązuje C# gdzie słowo struct generuje obiekty obsługiwane przez wartość (które mogą być niemutowalne ale formalnie nie muszą), to idealnie trafia w małe "byty" jak "homemade Date", miara z jednostką, Month rozumiany po ksiegowemu itd....
Tak, na pierwszy rzut oka to zupełnie inne zagadnienie, zmienne pośredniego stopnia złożoności na stosie bez sterty to wydajne, ale znakomicie wycina pytania o final referencję do mutowalnego obiektu.

Pomijając tą dyskusje na górze o słowie final.

To w JavaScripcie jeśli chcemy stworzyć obiekt z wartościami jedynie do odczytu to możemy wykorzystać getter

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

const person = {
  get name() {
    return 'Franek';
  },

  get age() {
    return 30;
  }
}

console.log(person.name) // Franek
console.log(person.age)  // 30

person.name = "Marek";
person.age = 24;

console.log(person.name); // Franek
console.log(person.age); // 30

lub Proxy / Reflect API

const person = new Proxy({}, {
  get(target, prop, receiver) {
    return Reflect.get(target, prop, receiver);
  },

  set(target, prop, val, receiver) {
    if (!Reflect.has(target, prop)) {
      return Reflect.set(target, prop, val, receiver);
    }

    return Reflect.get(target, prop, receiver);
  }
});

person.name = "Franek";
person.age = 30;

console.log(person.name) // Franek
console.log(person.age)  // 30

person.name = "Marek";
person.age = 24;

console.log(person.name) // Franek
console.log(person.age)  // 30

ZrobieDobrze napisał(a):

Dla mnie dyskomfortem jest w Javie rozbicie na typy elementarne i obiektowe, ale to było/jest ważne ze wzg wydajnościowych, jakby najgłupszy integer był pełnoprawnym obiektem (a tablica integrerów tablicą obiektów), to szybkość by siadła.

Ale przecież inne języki radzą sobie bez autoboxingu (o tym mówisz chyba?). Rust pozwala wywołać metody na liczbach, mimo że liczby to liczby, a nie struktury (w Rust struktury są odpowiednikiem obiektów).

Czemu więc w niektórych językach trzeba opakować wartość w obiekt, żeby wywołać na nim metody, a niektóre języki potrafią wywoływać metody nawet na liczbach bez opakowania tego w obiekt?

w Javie rozbicie na typy elementarne i obiektowe,

W Rust też jest coś takiego: https://doc.rust-lang.org/book/ch03-02-data-types.html

Ja w tym wątku który zadałeś, widzę dwa pytania ukryte pod pozorem jednego pytania.

1. Dlaczego słowo kluczowe const jest nazwane od "constant" skoro podczas uruchomienia programu wartości mogą być inne, i faktycznie to nie jest stała, tak jak PI.

   • Odpowiedź na to pytanie musi być dość zawiła. Deklaracja const w JS jest tożsama z final w Javie i readonly w C#. Dlaczego w ES6 taka deklaracja zmiennej której nie można zmienić wartości została nazwana "const" - ciężko powiedzieć. Być może dlatego że w JavaScript nie ma stałych jako takich - wszystko jest dynamiczne i wszystko może być prototypem wszystkiego. Być może miało być to "przeciwieństwo" var.

2. Dlaczego deklarowanie zmiennych które można tylko zdefiniować raz, ale nie można potem zmienić tego do czego się odnoszą (const) jest lepsze niż deklarowanie zmiennych które można redefiniować do woli (let).

   • Jeśli czytasz kod, i możesz założyć że raz zdefiniowana zmienna nie zmieni wartości, to taki kod jest przyjemniejszy i łatwiejszy do czytania, i też trudniej jest się pomylić. Jeśli zmienne mogą zmienić swoje wartości podczas działania, to to jest kolejne miejsce na buga albo jakiś błąd. Niemutowalne zmienne to właściwie podstawa paradygmatu funkcyjnego, i ma w sobie wiele zalet. Więc po prostu nieredefiniowanie raz zadeklarowanych zmiennych to dobra praktyka - tak dobra, że staramy się ją używać w całym projekcie i dodatkowo mamy słowa kluczowe które nas pilnują żeby to robić; dlatego używamy nieredefiniowalnych deklaracji (const, final, readonly). Zgadzam się że słowo const może być odebrane jako "stała", tak jak pi; ale można to wybaczyć bo w zasadzie w JavaScripcie nie ma stałych jako takich.