This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Deep JavaScript Foundations course:
The "Problems with let Keyword" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

Kyle describes a few issues he has with the let keyword. Some of his issues are stylistic, but others are related to common variable functionality like hoisting.

Get Unlimited Access Now

Transcript from the "Problems with let Keyword" Lesson

>> Kyle Simpson: What about for loops? How many of you do the for var i equals thing all the time? Anybody put your variable declarations in your for loops? This is a strong habit of mine. I put that var right there and I don't even think about it sometimes. I'm going to strongly suggest, as a matter of fact, another one of those rare places where I'll make, I will say that I have not come up with any reason at all, at least not yet, why you would want to continue doing for (var i.

[00:00:30] There's no place where for (var i is gonna be more preferrable than four (let i. The let declaration on the for loop is always gonna be preferrable to the var. So I just wholesale switched to that. I just always make my for loops with let key roots in them instead of with var key roots in them.

[00:00:50] One of the reasons for that is, I consider it to be a poor coding style to create a variable that I'm going to iterate over in a four loop. And then, be able to access that variable on the outside of the for loop. You can do that, and I certainly did that a bunch.

[00:01:05] But, in retrospect, I wish I hadn't done that. So, what I wish I had done is what I am doing here, which is essentially creating another variable on the outside that you can capture whatever thing you need on the inside of loop, and then use that variable. Here I could be capturing the value of i into this result variable and using it on the outside.

[00:01:22] That's yet another hint for your exercise. Okay?
>> Kyle Simpson: So you notice that I'm using the var for a variable that is intended to be used across multiple scopes. That's what var is better at. I could switch that to a let but here is why not to switch that to let.

[00:01:42] The presence of var keyword already has strong president in people's minds. It's a variable that attaches to the whole function and sometimes that 's exactly what you want. If you switch that to let. You have removed that stylistic signal from the reader of your code. Now they see a let result there and they don't know if you mean to only use it on that one line or if you mean to use it throughout the entire function, you can't tell.

[00:02:07] But if you use a var, you're signaling to them, this variable is intentionally left scope to the whole function cuz guess what its probably gonna be used in a bunch of places, so go ahead and keep using it. When we say let, we are going to say, hey neon sign, this thing is only going to exist right here.

[00:02:23] Having both those keywords in your code is a stronger stylistic signal difference. That helps readability. If you this and just switch all your vars to lets then you lose out on that stylistic signal. The fact is, some of your variables will need to be function scoped and some of them should be block scoped.

[00:02:44] So it should be let plus var, not let instead of var.
>> Kyle Simpson: Some people are asking me, well, okay, that's just a stylistic thing, why would I really need to still use var? There are places where I consider var to still be useful. One of those places where I think var is still useful is when I want a variable declaration to escape an unintentional block.

[00:03:12] This is one of those places. I don't know if anybody else uses try catches, but I regularly will either put them in intentionally, or add them in when I'm debugging something. And if I had used let id here to declare the id variable, and then gone back and wrapped a try around it, do you spot what the problem would be?

[00:03:30] Coz now all of a sudden my id variable would only exist inside of the try clause or the catch clause and wouldn't be accessible on the outside, so I'd create a different problem. This is one of those place where rather than create declaration separately and use it or whatever.

[00:03:48] The var keyword is more helpful cuz it can escape this unintentional scope. I'm also illustrating another thing that I really find to be useful here. You might wonder why did I re declare var in the catch clause. We know that var is gonna belong only once to the code.

[00:04:07] Why did I re declare var? It's because I have this belief that a variable declaration for readability sake only, that a variable declaration should be as close as possible to the first usage of that variable. If I declare a variable online one of my function but I don't use it for a thousand lines, and then I'm down 1,000 lines and I'm looking at the usage of the variable, I have to go looking for where it was declared so I know what scope it belongs to.

[00:04:35] Why not put the declaration as close as possible to where it's gonna be used?And that also goes for if I'm gonna use it in multiple different locations within a function. A rule of thumb that I use is, if I cannot see on one screen the usage of a variable and where it was declared, I redeclare it.

[00:04:58] So if I use it on line 1, and then 1,000 lines later I use it again, I go ahead and redeclare it down there so that it's super obvious what scope it belongs to. I can do that with the var keyword, I cannot do that with the let keyword.

[00:05:10] Let keywords can't be repeated, it would through an error if you try to do a let twice. Yes.
>> Speaker 2: I was, in my head I was trying to figure out, my question was going to be so why so often do you see all the declaration for the top?

[00:05:25] Why is that being talked cuz clearly someone's teaching it cuz when I go to other code bases, I see it that all the time.
>> Kyle Simpson: Yep.
>> Speaker 2: And I sort of answered that in my head thinking well, don't I know, want to know at the top of the scope, what are my variables are?

[00:05:36] So I know what I can name because if I'm declaring something in the middle of the code, I have to go look for it first.
>> Kyle Simpson: Why?
>> Speaker 2: To make sure that it's not already been declared.
>> Kyle Simpson: Not if you redeclared it everytime it's been used within your visual context of what you can see.

[00:05:49] If you declare it everywhere with a var, you can clearly see what scope it's in. And it should be okay to you to reuse a variable name if the word id is the right name for a variable. But you mean different things by id in different parts of the function.

[00:06:04] To me I don't think you need to necessarily come up with different variable names. Use the right variable name and if you need to reuse the variable that should be totally okay. If you reuse it, re-declare it so that it's super obvious, this is where this thing is coming from, it's coming from this function scope.

[00:06:19] I used to teach as did a bunch of people for like a decade, manual hoisting. Put all of your variable declarations at the top of your function. I take my vars out of my for loops, and put my var i [LAUGH] at the top of my thing. Like, I did it wholesale, exactly what you're saying and I now regret that.

[00:06:36] Because what I did was erase all the semantic signals, like for example putting it inside the if statement a few slides ago. I erased all of those stylistic semantic signals of where the intent, the intended usage was. So no I don't think we should put all our variables at the top of a function.

[00:06:54] You should ideally not have the declaration any more visually separated from its usage than what you can see on one screen. That would be my recommendation for readability.