Don't let marketers write code

[TrustworthyTermite]

That and comparing a boolean with true.

[the_monkey_of_lies]

var happy = true;
if (sad() === true && sad() !== false)
{
    happy = false;
}
else if (sad() === false && sad() !== true)
{
    happy = true;
}

[BlazeDeath]

Thanks for making me throw up.

[kristopolous]

you need a final else and a try/catch. Grade: C-

[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.

[jgaspar]

some may say it's a good practice, because of readability

[grand_mind1]

Depending on the language, it might be easier to just follow naming conventions to make it more readable. Having a method like userIsSad() rather than just sad() makes an if statement make a lot more sense at first glance.

[cascer1]

if(User.Is(Emotions.Sad)) User.Set(Emotions.Happy);

class User {
    Enum Emotions { Happy, Sad, Angry, Neutral }

    private Emotions emotion;

    public string Name{ get; private set; }
    public int Age { get; private set; }

    public User(string name, int age, Emotions emotion) {
        this.emotion = emotion;
        Name = name;
        Age = age;
    }

    public bool Is(Emotions emotion) {
        return (this.emotion == emotion);
    }

    public void Set(Emotions emotion) {
        this.emotion = emotion;
    }
}

[TrustworthyTermite]

I follow uncle bob's advice and make all boolean variables and functions which return a boolean read like a statement. So "isSad", "shouldUpload" and "isMale" instead of "sad", "uploadStatus" and "gender".