const is most likely is a very useful feature in certain situations. But what are those situations? I can only guess. I personally don’t think that I need const because I don’t think that accidental reassignments are an issue in my own code.
So what are those situations? That’s what people arguing for const should focus on explaining, in my option.
I think I have a good analogy. In CSS, I argue for using this code:
[hidden]{display:none1important;`}
The !important part is similar to const. It protects the display property from being re-assigned if the hidden attribute is present. Why is that important? Because a <div class="foo" hidden> element could get accidentally rendered with something that is as simple as .foo { display: flex; }. That .foo style may not have intended to style that specific hidden element but it did match it, and now the hidden attribute is ignored and the element is rendered.
So I think I make a good case for adding !important in this particular situation.
I would like someone to make a good case for why POST_TIMEOUT needs to be const. What concrete problem can be prevented by that?
It's about two things: semantics - code is not just meant for the computer, it's also for humans who read it. Using const better signifies to team members and maintainers that this variable shouldn't change. Another is safety by default. Yes, maybe your code doesn't have issues with constants. But it's about baking in safety to your code to reduce the possibility of any errors. It's like how Java class variables are package-private by default (like @flame10a
said) and it's highly recommended to make them private, and variables in Rust are actually immutable (non-reassignable) by default. So, in the future, if for example you're coding while running low on sleep, or one of your coworkers decides to work on it and he hasn't worked on the project before, you are a lot less likely to make a mistake.
I guess const makes (more) sense in large teams that work on large code bases (emphasis on I guess). I would like to see some practical evidence. If somebody was in a concrete situation where const saved them (and their team) from a nasty bug, I would like to read about it, so that I can get a feel of const’s usefulness.
If I started using const, I would have to decide every time when I declare a new variable, whether or not it should be re-assignable. This mental task seems unnecessary and annoying to me. I would rather spend my brain power on the actual problems that I’m trying to solve in my code.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Since I've switched to using const, I find that I almost never use let. In fact, the rarity of let makes it stand out in the code when it is used; it feels like a beacon to anyone reading the code that this variable is special, it's going to be updated later.
But I almost never update variables anyway. There are basically two cases where I use it:
In an old-fashioned for (let i=0; i<num; i++) loop
In a case where I'm setting the value inside of a block, either a complicated conditional situation or a try ... catch situation:
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Yeah, the difference seems to be that in a for ... of loop like this:
for(constthingofmyThings){/*...*/}
you're essentially grabbing an iterator at the start of the loop, i.e. myThingsIter = myThings[Symbol.iterator](), then at the beginning of each loop running const thing = myThingsIter.next(). It seems to desugar to something like this:
You're always assigning a whole new value to the loop variable as opposed to modifying the loop variable as is typical in a classic for (let i=0; i<n; i++) loop.
Really the only reason you need a let in that loop is because you're reassigning the value with i++, equivalent to i = i+. In theory you can use a const if you're doing something super unusual, like using an object as your loop variable and modifying a property of it:
I don't know why anyone would ever want something like this, and there would undoubtedly be cleaner ways to write the code, but it works. You're never reassigning o, so no problem with it being a const.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
const
is most likely is a very useful feature in certain situations. But what are those situations? I can only guess. I personally don’t think that I needconst
because I don’t think that accidental reassignments are an issue in my own code.So what are those situations? That’s what people arguing for
const
should focus on explaining, in my option.I think I have a good analogy. In CSS, I argue for using this code:
The
!important
part is similar toconst
. It protects thedisplay
property from being re-assigned if thehidden
attribute is present. Why is that important? Because a<div class="foo" hidden>
element could get accidentally rendered with something that is as simple as.foo { display: flex; }
. That.foo
style may not have intended to style that specifichidden
element but it did match it, and now thehidden
attribute is ignored and the element is rendered.So I think I make a good case for adding
!important
in this particular situation.I would like someone to make a good case for why
POST_TIMEOUT
needs to beconst
. What concrete problem can be prevented by that?It's about two things: semantics - code is not just meant for the computer, it's also for humans who read it. Using
const
better signifies to team members and maintainers that this variable shouldn't change. Another is safety by default. Yes, maybe your code doesn't have issues with constants. But it's about baking in safety to your code to reduce the possibility of any errors. It's like how Java class variables are package-private by default (like @flame10a said) and it's highly recommended to make them private, and variables in Rust are actually immutable (non-reassignable) by default. So, in the future, if for example you're coding while running low on sleep, or one of your coworkers decides to work on it and he hasn't worked on the project before, you are a lot less likely to make a mistake.I guess
const
makes (more) sense in large teams that work on large code bases (emphasis on I guess). I would like to see some practical evidence. If somebody was in a concrete situation whereconst
saved them (and their team) from a nasty bug, I would like to read about it, so that I can get a feel ofconst
’s usefulness.If I started using
const
, I would have to decide every time when I declare a new variable, whether or not it should be re-assignable. This mental task seems unnecessary and annoying to me. I would rather spend my brain power on the actual problems that I’m trying to solve in my code.Since I've switched to using
const
, I find that I almost never uselet
. In fact, the rarity oflet
makes it stand out in the code when it is used; it feels like a beacon to anyone reading the code that this variable is special, it's going to be updated later.But I almost never update variables anyway. There are basically two cases where I use it:
for (let i=0; i<num; i++)
looptry ... catch
situation:Neither of those are very common in my code, so I basically never use
let
.I'm glad to hear you're on the same page as me! I like the shining beacon analogy.
For me, both those examples often warrant extracting behavior to some helper function, but I understand how you're using them there, too.
That sounds like a solid approach. I’m surprised that
const
works fine in (the header of)for
-of
statements but not infor
.Yeah, the difference seems to be that in a
for ... of
loop like this:you're essentially grabbing an iterator at the start of the loop, i.e.
myThingsIter = myThings[Symbol.iterator]()
, then at the beginning of each loop runningconst thing = myThingsIter.next()
. It seems to desugar to something like this:You're always assigning a whole new value to the loop variable as opposed to modifying the loop variable as is typical in a classic
for (let i=0; i<n; i++)
loop.Really the only reason you need a
let
in that loop is because you're reassigning the value withi++
, equivalent toi = i+
. In theory you can use aconst
if you're doing something super unusual, like using an object as your loop variable and modifying a property of it:I don't know why anyone would ever want something like this, and there would undoubtedly be cleaner ways to write the code, but it works. You're never reassigning
o
, so no problem with it being aconst
.