const stands for constant, and it means the variable cannot be reassigned at a later time.
let is similar to var except that it is block scoped, which means it can be declared inside of a for loop and will be local to the body of that for loop (and therefor does not exist outside of it)
The latter is different from a var variable which can be declared anywhere but is always local to the function scope.
In general it is good practice to try and define your variables as const as much as possible.
const stands for constant, and it means the variable cannot be reassigned at a later time.
let is similar to var except that it is block scoped, which means it can be declared inside of a for loop and will be local to the body of that for loop (and therefor does not exist outside of it)
The latter is different from a var variable which can be declared anywhere but is always local to the function scope.
In general it is good practice to try and define your variables as const as much as possible.
As I meanwhile do almost exclusivey functional programming I find the destinction between const and let pretty useless.
I never ever reassign values to names. Never - regardless of the language.
Having said that I find the usage problematic due to 2 reasons.
constis longer thanlet(no seriously!)constsort of communicates back: Hey! I am constant but that is not true (well it is, but ...) I had multiple times collegues that were totally surprised
that this is possible
const x = { foo: "bar" }
x["foo"] = "Not bar!"
Sure the name and its reference is const but the object referenced is not. Granted in Typescript you can at least create
type ROO = Readonly<SomeType>
const x: ROO = someReferenceValue
x.someProp = "A wanna be a bar!" //compile error
So for Typescript const finally could mean const
TypeScript/ES2015: Prefer `const` instead of `let` reduces readability?
JS <> const vs let = should I always use const?
var, const, let
const vs let with symbol assignment
Videos
I confuse the following term var, const, let in typeScript and when should I use them?
*sigh*... This is why immutable needs to be the default. Even the referenced Java answer suggests this. Note that that answer does not recommend removing final modifiers, just that the author of that answer wouldn't add them in new code (for local variables) because they "clutter up" the code.
However, there is a difference between JavaScript and Java here. In Java, final is an additional modifier on a variable declaration, so you get:
final int foo = 3; // versus
int foo = 3;
In JavaScript, though, const is just an alternate variable declaration, so the situation is:
var foo = 3; // (or let nowadays) versus
const foo = 3;
I don't think two more characters constitutes "clutter". If the alternative being suggested is just foo = 3 then the reviewers are just wrong.
Personally, I would always use const when applicable and would suggest it's inclusion in a code review. But then I'm a Haskeller, so I would be like that. But also, JavaScript tends to be more pervasively mutable and have a worse debugging story when things do unexpectedly change, that I would say const in JavaScript is more valuable than final in Java (though it's still valuable there.)
As Ixrec points out, const only controls the modifiability of the binding, not the object that is bound. So it's perfectly legal to write:
const foo = { bar: 3 };
foo.bar = 5;
This can be used as an argument against using const as someone may be surprised when an "unmodifiable" object is modified. Newer versions of JavaScript do have a mechanism to actually make objects unmodifiable, namely Object.freeze. It makes a good addition to const (though only use it on objects that you create, for example, as Object.freeze({ ... })). This combination will communicate and enforce your intent. If used consistently, the times where you are mutating things will stick out and clearly signal non-trivial data flow.
It is indeed good practice to declare variables as const (or readonly or final, depending on the language) if possible.
The author of the linked answer also admits that is is right to mark variables as final, but the author is simply too lazy to do it.
Even if the authors opinion about "clutter" was right, then it wouldn't apply to JavaScript or TypeScript, since const is instead of let, not in addition to.
Since we can change the value of const by changing the object it is pointing to, then is it preferable to always use const? I'm probably getting a little ahead of myself, but I was just curious.