Freecodecamp: `var` should be discouraged.

Created on 13 Aug 2016  ·  3Comments  ·  Source: freeCodeCamp/freeCodeCamp

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.

discussing

Most helpful comment

@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.

All 3 comments

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 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.

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. ✌️

Was this page helpful?
0 / 5 - 0 ratings

Related issues

thecodingaviator picture thecodingaviator  ·  42Comments

Ethan-Arrowood picture Ethan-Arrowood  ·  56Comments

RandellDawson picture RandellDawson  ·  46Comments

sadathanwar17 picture sadathanwar17  ·  66Comments

no-stack-dub-sack picture no-stack-dub-sack  ·  44Comments