(Nevermind, I think FCC just means declaring a variable like a = 4)
This is from this lesson
I find this a bit shocking. I’m new to coding but have read elsewhere you should only declare variables with let and const. The following is from Udacity’s front-end style guide:
Is there really this much disagreement about variable usage among the developing community?This is from this lesson"
Yes, you are correct in both instances. When this was made, let and const weren’t around, so the point of this challenge isn’t what keyword to use but that you should always use a keyword when declaring variables. I would definitely agree with dropping usage of var altogether and primarily use const with let when needed.
In the beta version of the site, I believe this is taken care of in the ES6 section.
Also, you put (deleted) in the title, would you like me to hide the post?
Can I recommend leaving the thread here if OP doesn’t mind? It’s a good question and clears up an ambiguity in the wording of the challenge.
Thanks for clearing that up. Happy to leave it in case it helps someone else! (Removed “deleted” from the title.)
Agreeing that let and const are “safer”. There really isn’t a reason to use var anymore, not that I can think of.
What if you wanted your variable to be scoped to the nearest function block instead of the nearest enclosing block?
Yes, but then you could just declare the variable in that outer function. I think this is clearer than using var inside a block somewhere where it isn’t immediately obvious what the true scope is. A var declaration could be 1, 2, or 27 blocks deep. With let, it’s more clear, imho.
I remember an article where two opposite opinion was reported.
Ok, here it is:
JavaScript ES6 for Beginners #1 — Var vs Let vs Const & the temporal dead zone
Is that correct?
I agree for most cases I’ve encountered, and I barely use var anymore. There is the odd time though where I found using var to be more convenient.
I like Bynes’ rules:
- use const by default
- use let only if rebinding is needed.
- var should never be used in ES6.
I would disagree a little with the first line though. const should be used when you don’t plan on changing the variable. It should be noted that with non-primitives, you can still change the values, just not reassign them, but still that’s not how I use them.
I’m sorry Soup, I can’t think of a case where I must use var or where there isn’t any advantage. If I need access to it in the outer block, then it should be declared there. That and hoisting, imho, are a recipe for bad coding. I can’t think of anything I could do with var that I couldn’t do with let with proper planning. You can use var responsibly, but it can also be misused too easily. One complaint that I have with JS is that it is a little light and loose with its variables - this is a step in the right direction.
I should point out to beginners though, that you can’t just go back into old code and blindly change var to let - they have different scopes and the former has hoisitng. If you blindly change, you may break your code.
My comment was directed towards my own experience. I should have been clear. You’re correct that it’s possible to never use var and furthermore that you should no longer use it. Having said that, I still use it from time to time because while I’m still learning as an intermediate JS programmer, I believe I am experienced enough to use it safely. It’s a bit overkill to say that var is bad - it was used for a long time after all, before better alternatives came along. Just because something is a recipe for something bad, doesn’t mean that this thing must be avoided at all times. Yes, if I just started now, I would avoid it altogether. Yay for JavaScript’s flexibility.
Btw, when you said “That and hoisting, imho, are a recipe for bad coding”, I hope you meant variable hoisting, not function hoisting. Function hoisting is great!
Yes, but the point is that eventually you may want to work on code that other people may be working on. Or you may be working on a project big enough that you loose track of the scopes of various blocks. Yes, var can be used responsibly, the problem is that it allows itself to be used irresponsibly. If you think you can keep yourself from using it irresponsibly and can keep track of what scope is where across all the code blocks in all the files in all your projects and you’ll never need to work with other coders, then I guess it’s fine. Otherwise, let is a safer option. Having come from more stronly typed languages, I always thought var was a little hinky. Types in general, in JS, are hinky.
It’s a bit overkill to say that var is bad - it was used for a long time after all, before better alternatives came along.
I’m not saying it’s bad, just less safe and a better option is available. It’s an improved tool, that is inline with how these things work in a lot of other advanced languages. Yes, it was used for a long time. But now a better, safer, less prone to mistakes option is available. The only “advantage” to var is if you like being sloppy with you declare and scope variables. If you declare and scope them responsibly (in the right place, and in the proper scope) then they are essentially equivalent. Most languages would crash if you tried to declare variables the way var let’t you get away with. I think enforcing good planning and practices is a good thing. Again, I can find no real advantage to var.
I hope you meant variable hoisting, not function hoisting. Function hoisting is great!
Hoisting is a byproduct of the two-pass compilation that JS interpreters do. It was not a “feature” built into the language with purpose, afaik. Again, I think it is bad practice to rely on hoisting. Ideally, things should be declared at the top. Although I will admit that sometimes I move my helper functions to the bottom of the page for clarity. But other languages get by just fine without this. And if I wanted, I could just put them in their own file.
But in general, relying on the broad scoping of var and the sloppiness allowed by hoisting are not good and often the result of bad planning. They solve no problem that can’t be handled with good practices. All they do is open you up to possible errors or cryptic code. A quick check shows that that seems to be the general consensus.
Solid reasoning! I appreciate your detailed argument against using var.
I’ll try avoiding it moving forward; I was probably using it for maybe 5% of my declarations anyway so it shouldn’t be hard.
As for functions I generally use declarations rather than expressions due to the hoisting advantage, which I find super useful in many cases.
Agree with @kevinSmith’s detailed evaluation. There remains one scenario in which it’s useful to throw in the occasional var, though: in your browser console or similar REPL environments, at the top level of scope. If you’re trying out repeated iterations of a code snippet, var's sloppiness in allowing itself to be redeclared is handy.
On the other hand, you can also get around this by enclosing the whole snippet in {braces} to make it a block.
