This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.
Transcript from the "Const Keyword" Lesson
[00:00:00]
>> Kyle Simpson: Quick little note on the Const Keyword. A lot of people have actually taken to, now, they don't even say let instead of var. Now, they say use const everywhere. Every once in a while use let, and never use var. So the cult wisdom at this point is, always use const.
[00:00:16] If you have to switch back to let, and never use var. My advice is literally the opposite. Start out by using var. If you gonna block scope use let. Maybe everyone once in a while there's gonna be a need for a cons. Let me why my advice is the inverse of the community common.
[00:00:35] The cons key word implies a constant. And when I ask people what is a constant, I typically get answers like this, it's a value that doesn't change. That's the general dictionary definition for it. A variable that doesn't change. Well, that sounds all well and good, except that's not what we mean in programming by a constant.
[00:00:56] As a matter of fact, a constant, in any language in existence, const does not have anything to do with the value. Const, [COUGH], has to do with the assignment. A constant is not a value that doesn't change. A constant is a variable that cannot be reassigned. That might sound like an unimportant nuance, but actually it's a big, giant huge deal.
[00:01:18] And my evidence for that, is go do some searching on Stack Overflow, and see how many tens of thousands of questions in all languages, not just JavaScript have been asked over the years of people frustrated about this const key word in their language. And why does it work this way, and what does it mean, and what does it do, because they think that it's implying that we create a value that doesn't change, and that's not what it does.
[00:01:40] That history that precedent has been around for a really long time. We have adapted that history by bringing const into the JavaScript language. And we have people today, right now, probably right at this moment, writing on Stack Overflow, I don't know why const isn't doing what I think it should.
[00:01:55] It's mostly because they use stuff like line 7, they declared const and make it reference something, where the value itself is already a mutable value, like for example an array, or an object. What that means to the writer of that code, is they're thinking to themselves, well, c is never gonna get reassigned, but the reader of the code thinks, c is never gonna change.
[00:02:18] Do you see how those are different? Cuz if somebody changes c, and you're like, wait a minute, I thought it was a const, why is it changing? You've created a footgun for people to get tripped up on. The usage of the const keyword, in my book, already starts out in the negative column.
[00:02:35] Because it already has this confusing precedent for 30 or more years that it's been in programming languages. It already starts out with that. So for the const key word to actually be useful, it would have to somehow overcome that. It would have to be, not only good enough to overcome that negativity, but be significantly better, so that it would really encourage the user Java, it would carry its own weight.
[00:03:01] All this is one more the clear that I have to learn.
>> Kyle Simpson: And I don't think the const keyword really does that, I don't think it carries its own light. Does it have any benefit, whatsoever, it is a tiny amount of benefit. It might signal to a person, I'm not gonna reassigned this thing.
[00:03:19] But if you're using the const as a block scoping declared, which is what it is, and what it is supposed to be used for, if you use it in a block scope, your blocks are typically gonna be shorter in nature anyway, or at least that's best practice to have your blocks at five, or ten, or 15 lines, instead of thousands of lines.
[00:03:36] If you declare the const at the top of a block, say it's ten lines long, you say const x=2, and then,
>> Kyle Simpson: You have nine other lines within that block, and you don't reassign it, obviously, cuz it can't be reassigned. Supposedly, the benefit here is that you've told the reader of the code on line one, I'm not going to reassign it in any of the following nine lines.
[00:04:01] Cuz, by the way, those ten lines are the only ten lines in the entire program that can reassign that variable. Nowhere else can I reassign it, except for the block that it exist in. We know that, cuz we know how lexical scope works now. So you're saying, I'm not going to reassign it in any of the following nine lines.
[00:04:20] If you've done a good job of writing your blocks in a short enough way where they can be all seen at one time on the page, visually on your screen, the other way to signal to people that you're not gonna reassign it, is just to not reassign it.
[00:04:34] So is the const really providing that much benefit there? It's a tiny amount of benefit, at best. And it comes with this giant caveat of, people are gonna get confused about value versus assignment semantic. So I don't think the const keyword carries its own weight. It is only a tiny amount of benefit.
[00:04:54] So I still use const every once in a while. But I only use it for a value that's already immutable. For example, line 4. If I was declaring a variable like var pi equals 3.14, or something like that, I'd do it with a const. Makes complete sense, right?
[00:05:10] But I don't use const to declare my arrays, for sure. I don't use const to declare my functions, or any of that stuff, cuz I think I'm setting traps for people to fall into later.
>> Speaker 2: Can you elaborate on function expression? Why wouldn't you make a function expression a const?
[00:05:33]
>> Kyle Simpson: Why would I not make a function expression a const? Well, as I said earlier, my stylistic preference is that function declarations are more readable than function expressions assigned to variables. So I guess, in general, I would like to say that, there's another reason which we'll get to later in the course, when we talking about hoisting.
[00:05:51] Function declarations behave differently than function expressions, and I tend to prefer the behavior of a function declaration over a function expression.
>> Kyle Simpson: But in a more narrow sense, I wouldn't do it, because it doesn't offer any benefit.