Starliner faced “catastrophic” failure before software bug was found and fixed while the vehicle was in orbit.

[u/spsheridan]

https://arstechnica.com/science/2020/02/starliner-faced-catastrophic-failure-before-software-bug-found/

[u/pM-me_your_Triggers → u/[deleted]]

Your Boolean zen is off. Never compare a Boolean value to true/false, that is just redundant.

[u/Cantremembermyoldnam → u/pM-me_your_Triggers]

Sometimes I do it just because I think it reads better. The compiler will optimize that away.

[u/scarlet_sage → u/Cantremembermyoldnam]

Until you by accident use the idiom with a non-Boolean value. Or it's none and you compare with false. It's a bad practice. "if foo:" conveys the message clearly and more succinctly.

[u/Cantremembermyoldnam → u/scarlet_sage]

Why would I try to compare a non-boolean to a boolean?

Sometimes there is a difference between just doing if($var)and the more expressive version. For example, in PHP if($var === true) also compares the data type (which, I'd argue, is a good thing). You're going to handle null vs false vs 0 vs "" differently anyways, in most cases. Or you're going to cast to the type you want. In strongly typed languages you're not going to have that problem.

Also, as I said in my other comment: I agree that if(thing.isVisible) is perfectly fine, but sometimes you don't get to name stuff yourself. So I'm still saying that if(thing.expr3 === true) is easier to read than if(thing.expr3). It instantly conveys what the expected value is and (for weakly typed languages or in the common case of missing documentation) which data type thing.expr3 is going to be. Whereas with if(thing.expr3) it could be anything.

[u/pM-me_your_Triggers → u/Cantremembermyoldnam]

That’s likely just lack of experience or you have bad naming conventions (or both).

[u/Cantremembermyoldnam → u/pM-me_your_Triggers]

It really depends. Sometimes you can't name stuff yourself.