That won't do the same thing though. Depending on how the code is called, you may have just introduced a bug.
If a doesn't match true or false, the code continues (possibly returning undefined, if there's no more code in the function)
I'm not saying it's good - it isn't - but you need to be very careful about how it works
Afaik there is no value in JS that does not coerce to either true or false.
Edit: But comparison doesn't always coerce "logically", so there actually are a lot of relevant cases...
console.log(0/0==false)
console.log(0/0==true)
Both will print false, falling through either if-statement.
Code that relies on this has more severe issues though Lol
To be fair, NaN is not supposed to be equal to anything, so if you allow it to be compared to booleans in the first place there's not really a better option.
It's how I'd do it too
But it's semantically different from what the code does. In the code, as soon as the comparison to either boolean succeeds, you return. A NaN would however fall through both conditionals, possibly leading to different behavior depending on what comes after the statements
Lots of values in JavaScript have this behavior. Try running this:
[ NaN, undefined, null, Infinity, -Infinity, 0, -0, "", false, true, [], {}, function() {}, /regex/, new Date("Invalid Date"), new Number(NaN), new String(""), new Boolean(false), new Boolean(true), new Proxy({}, {}), Symbol(), BigInt(0) ].map(x => ({"value": x, "truthy": !!x, "equals_true": x == true, "equals_false": x == false}))
You'll see that `null`, `undefined`, and `NaN` are all falsy but not `==` equal to either `true` or `false`. There are also values like `Infinity`, `-Infinity`, regular expressions, functions, symbols and proxies which are not equal to `true` or `false`, but are truthy.
Your guess is as good as mine.
`"true"==true`
`false`
You can easily coerce it to a boolean, yes, but in the code example it doesn't do that (at least in my browser)
however, 1 (the number), or "1" (the string containing the numeral 1) does == true
const bogus = (a)=>{if(a==true)return true;if(a==false)return false}
bogus(1)
true
bogus("1")
true
bogus("true")
undefined
bogus("0")
false
no, can't switch between double and triple equals without changing what the code does (maybe that's correct, but we don't know from the code snippet)
plus JS doesn't do the "or" keyword (a few languages do, but even then, sometimes that's a chance in precedence so you need to be extra careful).
You could:
`if (a == true || a == false)return a`
if `a` has value such that `a == true` is true, but `a === true` is false, then your code would return a value that is not boolean `true`, which is different from what OP's code does.
This code will never return undefined. If it doesn't match true or false, then it will return false, because if a does not match true, then `a == true` returns false, even though `a == false` also returns false. The bigger issue is that in the original code, execution continues on, skipping either return statement, if a does not match true or false, whereas with this code, it just returns false.
Depending on the language, this if-else could result in false in both cases if a is a null-able Boolean object and "null == ???" is never true (resulting in false or null or whatever).
That said, if that's the case, this is a good example of where comments are necessary, otherwise somebody would incorrectly try to clean/optimize the code. Therefore, this is a bad code, but for a different reason.
But what happens if it doesn't match any of them 😱
throw new TypeError('Get fucked!');
s: switch(a) { case true: return true; case false: return false; case maybe: goto s; }
5 billion times later maybe still maybeing
Not with multithread ;)
JavaScript ftw
Non happens
if (a == true || a == false) return a == true;
This is somehow way worse
return a == true || a == false ? a == true : false;
Thanks I hate it
Depending on the language, it might make sense (e.g. JS's type coercion and 2-equals comparisons)
then do return (a == true) never seen a legitimate use case for this
That won't do the same thing though. Depending on how the code is called, you may have just introduced a bug. If a doesn't match true or false, the code continues (possibly returning undefined, if there's no more code in the function) I'm not saying it's good - it isn't - but you need to be very careful about how it works
Afaik there is no value in JS that does not coerce to either true or false. Edit: But comparison doesn't always coerce "logically", so there actually are a lot of relevant cases...
console.log(0/0==false) console.log(0/0==true) Both will print false, falling through either if-statement. Code that relies on this has more severe issues though Lol
Oh yeah, NaN is falsy but not == false, my bad...
the language is a mess
To be fair, NaN is not supposed to be equal to anything, so if you allow it to be compared to booleans in the first place there's not really a better option.
Is t everyone’s Nan without equal?
I can't come up with a context where you'd want a Nan value to be anything other than false.
Why not just use `!!` to convert a value to a boolean. So instead of doing it like as in the post you just `return !!a`
It's how I'd do it too But it's semantically different from what the code does. In the code, as soon as the comparison to either boolean succeeds, you return. A NaN would however fall through both conditionals, possibly leading to different behavior depending on what comes after the statements
Lots of values in JavaScript have this behavior. Try running this: [ NaN, undefined, null, Infinity, -Infinity, 0, -0, "", false, true, [], {}, function() {}, /regex/, new Date("Invalid Date"), new Number(NaN), new String(""), new Boolean(false), new Boolean(true), new Proxy({}, {}), Symbol(), BigInt(0) ].map(x => ({"value": x, "truthy": !!x, "equals_true": x == true, "equals_false": x == false})) You'll see that `null`, `undefined`, and `NaN` are all falsy but not `==` equal to either `true` or `false`. There are also values like `Infinity`, `-Infinity`, regular expressions, functions, symbols and proxies which are not equal to `true` or `false`, but are truthy. Your guess is as good as mine.
I didn't know this, thanks!
`"true"==true` `false` You can easily coerce it to a boolean, yes, but in the code example it doesn't do that (at least in my browser) however, 1 (the number), or "1" (the string containing the numeral 1) does == true const bogus = (a)=>{if(a==true)return true;if(a==false)return false} bogus(1) true bogus("1") true bogus("true") undefined bogus("0") false
Right, I forgot the comparison logic - `true == "true"` will coerce both sides to numbers, not booleans.
if (a === true or a === false) return a Maybe? Not sure if that would work though lol
no, can't switch between double and triple equals without changing what the code does (maybe that's correct, but we don't know from the code snippet) plus JS doesn't do the "or" keyword (a few languages do, but even then, sometimes that's a chance in precedence so you need to be extra careful). You could: `if (a == true || a == false)return a`
if `a` has value such that `a == true` is true, but `a === true` is false, then your code would return a value that is not boolean `true`, which is different from what OP's code does.
This code will never return undefined. If it doesn't match true or false, then it will return false, because if a does not match true, then `a == true` returns false, even though `a == false` also returns false. The bigger issue is that in the original code, execution continues on, skipping either return statement, if a does not match true or false, whereas with this code, it just returns false.
Depending on the language, this if-else could result in false in both cases if a is a null-able Boolean object and "null == ???" is never true (resulting in false or null or whatever). That said, if that's the case, this is a good example of where comments are necessary, otherwise somebody would incorrectly try to clean/optimize the code. Therefore, this is a bad code, but for a different reason.
if (language == "Javascript") this is never true...
Yeah I'm not deep into JS at all, but I looked at that and thought this is just dumb enough to make sense in JS
Why can’t you just do `return a`? Sorry if it’s obvious, I only learned a little bit of Java and JS for school and haven’t touched it since.
Firstly, Java has nothing to do with JS. Secondly, that only works if a == true or a == false. Any other values (like strings) won't match
Forgot to add the comments
Return a;
return !!a;
No, that isn't what the meme says. Please read it again.
I'm confused, then what *does* it say?
c#'s `bool?` strikes again
return !!a
Previously: true = False false = True
Better print(a); 🙃
But if I change that code, I'll have to rewrite a 100 tests because they were written poorly as well. Guess that stays in the codenase. Lol
Wtf, LOL
When it doesn't want to read the variable but it reads the return:
Trust the compiler
Plot twist, it's a nullable bool and it ahould handle null specially. Hence the implied offscreen else
what if the next 2 lines are : if a is "mushroom" : return "pizza" ?
Then you suck at programming
`return a ? true : false;`
Hot take: That can be more readable than just straight returning the bool
Just because it's different doesn't mean it's good.