someBoolean = (condition1 && condition2 ) ? true : false;

O.M.G....

Ok

better then

bool valid = false;
If(condition1 == true){
if(condition2 == true){
valid = true;
}
else{
valid = false;
}
}
else{
valid = false;
}

My eyes bleed most days.

@C0D4 I see this too often at work, it makes me wanna cry.

@C0D4 you and me both.

One day I found a line like that in our codebase… immediately checked git blame cause I wanted to know who the duck does that: it was me myself.

Though in my defense, judging from the date, it must’ve been one of my first commits ever to any codebase. And then I was left to wonder how nobody mention it at PR..

@100110111 "oh, I know this man. It's me!"

if (isApp || true) ...

This makes sense if condition2 is not a boolean

@bioDan it just cannot not be a boolean.

@iiii why not?

What's so wrong with it, assuming that boolean is reused somewhere?

@Shadowleaf seriously, you don’t see what’s wrong with that? Hint: it’s not the assignment…

@100110111 You mean unnecessary brackets? Otherwise not really...

@bioDan because it will be converted to boolean to get a boolean result anyway. So it's either a boolean ot trivially convertible to boolean

@Shadowleaf the tested result is already a boolean. There's to need to test it and return a boolean yet again.

@Shadowleaf you’re either real green or in the wrong business, then.

@Shadowleaf the true/false implicitly returned is redundant.

x = (condition1 && condition2)

Is more then enough.

@iiii so tell me what does the following evaluate to?

const areYouSureImBool = (true && {})

const areYouSureImBool2 = (true && '')

const areYouSureImBool3 = (true && [])

@bioDan if you end up with a situation like that, your code is already shit

@100110111 im not saying its not, im just saying there are cases where its valid to be that explicly in JS

@100110111 btw, its only speculation but i bet you can find shit in 85% of code bases

@100110111 For some reason was looking what's wrong with comparisons, not type. Guess i need to wake up before posting.

@bioDan I guess that’s a way to handle those cases, yes. Does lead to the question whether JS is ever a valid language choice, really. 😏

@bioDan let's not talk about shitscript

@iiii this post is about shitcode, its in the tags

i hope you now understand there are use cases where its valid, and that it depends on the type of the second condition.

JS is a weak and dynamic type programming language, lamentably there are cases where this is a valid solution.

@bioDan shit code but not shitscript 🙃

@bioDan I would argue that checking an array, for example, for emptiness should be made with an 'empty' method, and not via automatic conversion to boolean.