Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

var should be discouraged. #10199

Closed
piq9117 opened this issue Aug 13, 2016 · 3 comments
Closed

var should be discouraged. #10199

piq9117 opened this issue Aug 13, 2016 · 3 comments
Labels
status: discussing Under discussion threads. Closed as stale after 60 days of inactivity.

Comments

@piq9117
Copy link

piq9117 commented Aug 13, 2016

Challenge Global Scope and Functions has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.

My code:

// Declare your variable here
var myGlobal = 10;

function fun1() {
  // Assign 5 to oopsGlobal Here

}

// Only change code above this line
function fun2() {
  var output = "";
  if (typeof myGlobal != "undefined") {
    output += "myGlobal: " + myGlobal;
  }
  if (typeof oopsGlobal != "undefined") {
    output += " oopsGlobal: " + oopsGlobal;
  }
  console.log(output);
}

We need to start using es6 let and const. var variable declaration is a potential for a bug.

@BKinahan
Copy link
Contributor

ES6 features including let and const will be covered in detail in new curriculum topics which are currently being developed (see here). These challenges will also go over the problems which can be caused by scoping/hoisting when using var.

For now this challenge serves as an introduction to scoping and some of the issues to look out for when var is used, and still contains useful information as campers are likely to come across code from other (older) sources which do use var (eg legacy code, etc), and so it is a useful introduction to the issues discussed.

There might be an argument for removing the line

You should always declare your variables with var.

or altering it with some caveat regarding learning about let and const later on, but I think this challenge is fine for a first introduction to the topic.

cc @FreeCodeCamp/issue-moderators Thoughts?

@BKinahan BKinahan added the status: discussing Under discussion threads. Closed as stale after 60 days of inactivity. label Aug 14, 2016
@BerkeleyTrue
Copy link
Contributor

@BKinahan Well put.

When to use and not use var is not always up to the individual developer but most of the time it depends on the team.

While I have not found a time where var could not be replaced with let or const I have spoken to an engineer at OpenTable, which had recently refactored their whole codebase to use ES2015, and he did mention there was one case where let or const was the cause of a bug and var had to be used but he could not remember the exact details of why that was.

I don't think var should be discouraged. Better to explain the way var works and let the developer choose once they are further along on their journey towards enlightenment.

There are also some weirdness with let and const that if you are not aware of it can through you through some loops (see: temporal dead zone). This does not disqualify let and const from being used, even though it is an annoyance. It just means that grokking a thing is as important as knowing a thing.

@piq9117
Copy link
Author

piq9117 commented Aug 15, 2016

Thank you for the inputs. They're both good points. I guess this is all opinion based. However, I would stand by my statement, and I would go as far as to preach to use immutable data, and use libraries like immutable.js or mori to prevent unexpected data mutations. ✌️

@piq9117 piq9117 closed this as completed Aug 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: discussing Under discussion threads. Closed as stale after 60 days of inactivity.
Projects
None yet
Development

No branches or pull requests

3 participants