* sigh * ... Questo è il motivo per cui l'immutabile deve essere l'impostazione predefinita. Anche la risposta Java referenziata suggerisce questo. Si noti che la risposta non consiglia di rimuovere final modificatori, solo che l'autore di quella risposta non li aggiungerebbe nel nuovo codice (per le variabili locali) perché "ingombrano" il codice.
Tuttavia, qui c'è una differenza tra JavaScript e Java. In Java, final è un modificatore aggiuntivo su una dichiarazione di variabile, quindi ottieni:
final int foo = 3; // versus
int foo = 3;
In JavaScript, però, const è solo una dichiarazione di variabile alternativa, quindi la situazione è:
var foo = 3; // (or let nowadays) versus
const foo = 3;
Non penso che altri due personaggi costituiscano "confusione". Se l'alternativa suggerita è solo foo = 3 , i revisori sono semplicemente sbagliati.
Personalmente, utilizzerei sempre const quando applicabile e suggerirei l'inclusione in una revisione del codice. Ma poi sono un Haskeller, quindi sarei così. Ma anche JavaScript tende ad essere più pervasivamente mutevole e ha una storia di debug peggiore quando le cose cambiano inaspettatamente, direi che const in JavaScript è più prezioso di final in Java (anche se è ancora prezioso lì.)
Come sottolinea Ixrec, const controlla solo la modificabilità del bind, non l'oggetto associato. Quindi è perfettamente legale scrivere:
const foo = { bar: 3 };
foo.bar = 5;
Questo può essere usato come argomento contro l'uso di const in quanto qualcuno potrebbe essere sorpreso quando un oggetto "non modificabile" viene modificato. Le versioni più recenti di JavaScript hanno un meccanismo per rendere gli oggetti effettivamente non modificabili, ovvero Object.freeze . Fa una buona aggiunta a const (anche se lo si utilizza solo sugli oggetti che crei, ad esempio, come Object.freeze({ ... }) ). Questa combinazione comunicherà e imporrà il tuo intento. Se utilizzati in modo coerente, i tempi in cui si si modificano le cose si attiveranno e segnaleranno chiaramente il flusso di dati non banale.