4/11 Brevity


According to the explanation accompanying this exercise, you can safely leave out the triple-equals operator (===) in this code:

var myNumber = 1;
while(myNumber) {
    // Do something!

But surely that's not the case? There's an important difference between (implied) == and ===.

The first compares two variables using type coercion, i.e. forcing the variables to be of the same type (string, number, boolean, etc). So (myNumber == true) will evaluate to true.

The latter compares the variables' values and their types. (myNumber === true) is false, because myNumber is a number variable and true is a boolean. (See here for a further explanation.)

Try the code below. It will log "(test) is true" but not "(test === true) is true".

var test = 1;
  while (test) { // true, even though 1 is a number and true is a boolean
    console.log("(test) is true");
    break; // prevent infinite loop
  while (test === true) { // false, because test is a number and true is a boolean
    console.log("(test === true) is true");

Am I missing something, or is this exercise wrong?


No your correct about the == and ===. Seems like while only uses something comparable to == to check if its condition is true. As you can see:
1 acts "truthy" when used in conditions as you've checked yourself. So using 1 is possible, side-note and in languages like C where you have no boolean values by default it is even common. So what exactly is your question?


Well, I guess it's not really a question. I was wondering whether the advise given in this exercise was correct, and I think it probably isn't.

Suppose this is your code:

var myNumber = 1;
while(myNumber === true) { //evaluates to false
    // Do something! // this code doesn't execute!

If you follow the advise given, you would replace (myNumber === true) with (myNumber), and suddenly your code does something different:

var myNumber = 1;
while(myNumber) { // evaluates to true
    console.log("This shouldn't be happening!"); // But it does!

So unless your variable is a boolean (for example, in the while loop in the Dragon Slayer, which evaluates the boolean variable 'slaying'), you can't safely shorten (myVar===true) to (myVar), because that may very well change what your code does, and introduce unpredictable errors that are hard to debug.

In the example given with the exercise, myNumber is a number. So (myNumber===true), which evaluates to false, is not the same as (myNumber), which evaluates to true. In this case though, if you mean ===, then you really should use ===.


Comparing booleans to true is pretty redundant if you think about it!

Anyway, myNumber is, as you say, not a boolean, so reading this from a C perspective, while (myNumber) means "while myNumber is not 0" which is not the same as testing if it's true, but it's a perfectly valid test.

We do this in Python too, values can be truthy or falsy. Empty containers are falsy, as is 0 and None (equivalentish to JS's undefined).. So if we're popping things from a list until it's empty, we might do:

while (myList):

instead of:

while (len(myList) > 0):

I would not compare myNumber to true, because it's not a boolean, and comparing to true is a bit bleh, I think booleans should be named in such a way that there's no need, like so:

while (keepGoing) {}
while (isPurple) {}

In the case of myNumber, I would be fine with while (myNumber) but if I wanted to be more explicit I might write:

while (myNumber > 0) {}

An advantage with this is that it'll turn false for negative values, unlike when using the value on its own as the condition. It could also be seen as a disadvantage because then a bug causing myNumber to become negative would cause the loop to stop, instead of becoming infinite, and the bug might not get noticed.

I'd say being explicit is a good thing, but if it adds too much clutter it may be better to omit such comparisons. Variable names help a lot and the general goal is to make it read almost like natural language, or to use common patterns that everyone immediately recognizes.