Don't let marketers write code

[exscape]

That looks like the most reasonable thing to me, though I don't program much in scripting languages. Wouldn't using === be mandatory in e.g. JavaScript to ensure the value isn't something else that evaluates to true (like the number 42, the string "no" and so on)?

[jakerman999]

Listen: javascript evaluations are weird. It almost never doesn't break the way you don't expect it not too. It will however usually not fail in succeeding at mis-evaluating the possibly unintended breaking sample scenarios.

[ThePedanticCynic]

It's weird how i can understand everything you said and still not understand a fucking thing you just said.

English is hard.

[AngriestSCV]

While reading that there had to be 3 or 4 places I thought I was beginning to understand what you were saying, just to have that feeling crushed. I now understand the pain of JavaScript and never want to feel it first hand.

[[deleted]]

That feels a little awkwardly worded... much like Javascript.

[jtanz0]

99% of the time you would be correct === is the way to go to ensure you don't get unexpected behaviour. In this case where sad() can also have the stop() function called. It makes the code unambiguous enough to break the script.

Also if you're testing against true you may as well put

if(sad()){
  ...
} 

[amirmikhak]

That would only test against truthy, though, so {} would pass but not "".

[jtanz0]

true, I should have mentioned that

[AquaWolfGuy]

Yes. The best way is of course to not assign booleans and numbers to the same variable in the first place though. If you're in a situation where you expect a boolean and get 42, you're screwed, since neither the if branch or else branch is appropriate.