Why do we write `if(sale)` instead of `if(sale===true)`?

Not quite understanding why wouldn’t write
If (sale === true)
instead of
if (sale)
at the beginning.

It doesn’t seem to make sense. Can anyone explain the logic there?

I let sale = true;

sale = false;

if(sale) {
console.log(‘Time to buy!’);
} else {
console.log (‘Time to wait for a sale.’)


That would be,

if (sale === true)

Note the comparison operator. = by itself is assignment.

The conditional argument of an if statement always yields a boolean so direct comparison to a boolean is redundant. We only need to test for truthiness

if (sale)

does just that.


Thanks @mtf . Perfectly explained. Many thanks.


You’re welcome!

Eventually we all get a handle on truthy and its counterpart, falsy. This is a valuable tool to have in our kit.


In all the examples provided so far for conditional statements, the condition is either ‘if (true)’ or ‘if (false’. However, in the instructions, I am told to write ‘if (sale)’. Is it only possible to make the condition something other than true/false if the previous line has a boolean variable? Thanks



The variable needn’t be a boolean value, but is set to one for the example. As illustrated, the action in the if statement block will not execute since the variable is set to false.

if (condition) {
     // action code to run only if condition evaluates to true

In the above, condition can be any expression, not necessarily an explicit boolean primitive. Since the code branch is only followed when the condition is true, we would never write,

if (false) {

  1. I didn’t get it sorry. Can you explain me more… Do you mean that sale===true doesnt implying sale to be boolean?
  2. Also tell me if booleans are like numbers and we can’t write them quotes like “true”. we write numbers as 6 (without quotes) so will “true” make true from boolean to string…Are boolean logical operators like arithmetic operators :thinking:

Assuming this to be true, yes, ‘sale’ is a boolean. The comparison is also boolean, just not literal.

Correct, since that would make it a string.


are boolean literals. The only two primitives of their type.

The two can be coerced to numbers, false => 0, true => 1


Even though it’s redundant as you pointed out, can you still use it if you want to?

For instance, can you still use this

If (sale === true)

if you want to?

Nothing is stopping you but it will soon fall out of fashion, especially as you venture into larger projects. Redundancy is a debugging nightmare.

I cannot speak to any interview questions, though. One would hope not to see that in an answer, there.

OKay! Formerly, the interchange between the 2 styles created a bit of confusion about which is correct or not in certain scenarios. But it’s clearer now that direct comparison to a boolean is equally correct, albeit old-fashioned and/or redundant.


1 Like

Thank you so much. The lession that directs here was a little vague as to the relevancy of if… else being an indicator of truthiness. That’s the perfect Colbertism for understanding this lession.

1 Like


I do believe that if(condition) and if(condition === true) are not identical

if(condition) is checking if the condition evaluates to true (if it is a truthy value) while if(condition === true) is checking if the condition is identical to the primitive boolean true

let name = "Samy";

if(name) {
  console.log("This line will get executed");

if(name === true) {
  console.log("This line will not get executed");

Yes, there is a difference between identity and truthiness. Identity is exact, truthy is anything that is not falsy. true is not falsy so,

 if (sale) 


if (sale === true)

will both be the same only when sale === true.

I still say we do not need to equate a value with true if all that matters is truthiness.

1 Like

So if you wanted to check if sale was a truthy value, you would write:

if (sale)

but if you wanted to check if sale was equal to the boolean true, you would write:

if (sale === true)

It is rare that we would actually need to test for true, since a truthy test will have the same outcome. If it is imperative that it be true then one supposes test for the value identity, but I fail to see an actual need for that level of exactness.


Thank you very much.


Thank you I :blush: really got it would you please answer whenever I ask a question??

1 Like

this can only be used when the variable is set as true or false right? for instance…

let code = 2
if (code) {
console.log(‘bla bla’);

that will return an error because code at that point code can be anything. i get it :slight_smile:

Not so. It can be used on any value, number, string, object. The evaluation is whether it is truthy or falsy. In the case above, 2 is truthy.

Falsy values include,

0          =>  zero
'0'        =>  zero represented in string form
''         =>  the empty string
null       =>  the null object
undefined  =>  undefined variable or return
NaN        =>  Not a Number

Pretty much everything else is truthy.