in nearly 30 years I have never had a bug introduced into my code because a local function variable was mutable when I didn’t expect it. It does nothing for me to aid in code analysis or tracking. It has at most a tiny impact on performance.
This is a huge annoyance of mine in JavaScript. JavaScript const only prevents reassignment, so using it with function local objects is a waste of time (and a source of bugs where junior devs might naively believe that the object is immutable), but it’s very popular for some reason. Yet I have essentially never seen a bug caused by function local reassignment. The closest thing to it is that in Vue 3, you should do x.value = thing instead of x = thing, so declaring x as const does help prevent bugs. But it’s really just a weird quirk of Vue 3’s reactivity system that makes it valuable.
I have no idea why JavaScript has const for local variables but IME it is very useful in Typescript because TS uses constness of variables to make type guards more useful. Especially in async code.
e.g. if I have const x: string | null = ... and I write if (typeof x === "string") { ... } then inside the body of that if statement Typescript continues to believe that x is a string. Whereas if I write let there then the information that Typescript inferred from control flow gets invalidated quite quickly (offhand I think at any function call and after any await in an async function).
On the other hand, since const and let were standardized I’ve never needed to use let (reassignement) outside of a rare for (let i = start; i < n; i += step). I always use const on the basis that while I don’t need reassignement I shouldn’t enable it.
That’s a nice zugzwang, he can’t respond with the obvious retort “I didn’t spend a second thinking about it; I just used const” because then he’ll have spent more energy on the argument and lost by the metatheory that you put in place.
Because let semantically means “I’m going to reassign to this binding later on” while const means “this binding is assigned to only once here”. Like yourself I didn’t really think about it. That just makes sense to me.
You could have blorf mean you’re going to access a variable an odd number of times and splork mean you’re going to access it an even number of times. You could probably even get very quick at knowing in advance whether a variable if a blorf or a splork. It’s still a waste of time because odd versus even access doesn’t cause bugs and so there’s no reason to keep track of it whatsoever.
Mutation causes bugs. Reassigning a local looks similar to mutation, but unlike mutation it is not a source of bugs. People want const to do something about mutation because that’s the source of bugs, but it just doesn’t. It instead prevents reassignment, which is a waste of time. Use const for exported values and primitives (which has the side effect of making them immutable, which is what you want). Don’t use const for local objects because you’re not preventing any bugs.
This is a huge annoyance of mine in JavaScript. JavaScript const only prevents reassignment, so using it with function local objects is a waste of time (and a source of bugs where junior devs might naively believe that the object is immutable), but it’s very popular for some reason. Yet I have essentially never seen a bug caused by function local reassignment. The closest thing to it is that in Vue 3, you should do
x.value = thinginstead ofx = thing, so declaring x as const does help prevent bugs. But it’s really just a weird quirk of Vue 3’s reactivity system that makes it valuable.I have no idea why JavaScript has const for local variables but IME it is very useful in Typescript because TS uses constness of variables to make type guards more useful. Especially in async code.
e.g. if I have
const x: string | null = ...and I writeif (typeof x === "string") { ... }then inside the body of that if statement Typescript continues to believe that x is a string. Whereas if I writeletthere then the information that Typescript inferred from control flow gets invalidated quite quickly (offhand I think at any function call and after anyawaitin an async function).On the other hand, since
constandletwere standardized I’ve never needed to uselet(reassignement) outside of a rarefor (let i = start; i < n; i += step). I always useconston the basis that while I don’t need reassignement I shouldn’t enable it.I always use let on the basis that it’s shorter and looks better to me.
Why? Reassigning locals doesn’t cause bugs. Why spend even a second thinking about it?
That’s a nice zugzwang, he can’t respond with the obvious retort “I didn’t spend a second thinking about it; I just used const” because then he’ll have spent more energy on the argument and lost by the metatheory that you put in place.
A functional programming mentality encourages immutability by default.
But const is mutable. That’s literally the whole complaint I have about it. That’s why I don’t think you should use it in most cases.
Because
letsemantically means “I’m going to reassign to this binding later on” whileconstmeans “this binding is assigned to only once here”. Like yourself I didn’t really think about it. That just makes sense to me.Both convey some intention to me.
You could have blorf mean you’re going to access a variable an odd number of times and splork mean you’re going to access it an even number of times. You could probably even get very quick at knowing in advance whether a variable if a blorf or a splork. It’s still a waste of time because odd versus even access doesn’t cause bugs and so there’s no reason to keep track of it whatsoever.
Mutation causes bugs. Reassigning a local looks similar to mutation, but unlike mutation it is not a source of bugs. People want
constto do something about mutation because that’s the source of bugs, but it just doesn’t. It instead prevents reassignment, which is a waste of time. Use const for exported values and primitives (which has the side effect of making them immutable, which is what you want). Don’t use const for local objects because you’re not preventing any bugs.