Conditional breakpoints in Visual Studio

Sometimes you do something and you never really think about what you’re doing.
Like the following code:

public bool TestSomething(bool input)
{
    if (input == true)
    {
        return true;
    }
    else
    {
        return false;
    }
}

It’s so obvious, I never thought about what I was really doing there, let alone seen the mistake I made. I mean, without any knowledge about boolean evaluation you still should figure out how to get rid of the bracket porn and produce something like this:

public bool TestSomething(bool input)
{
    if (input == true)
        return true;
    return false;
}

But that’s only syntactic, the whole statement itself is still silly. The whole == true is completely redundant because you already check a boolean condition to evaluate it to a boolean.

So it boils down to:

public bool TestSomething(bool input)
{
    return input;
}

And that’s it. You just saved yourself 6 lines of code that where completely useless (and I guess the compiler is smart enough to optimize that anyway  Update: actually, this does make a difference. The compiler can’t figure this out and will produce more IL code because of this).

But once I did this I felt I lack the ability to put a breakpoint on the return false statement. And I eventually may have thought about going back to solution #2. But then I found this little thing in Visual Studio that made my day (and all major IDEs have that, only they hide it well):

When you right click a breakpoint you can add a Condition to it, so it will only break when that condition is met. I did so, and voila:

Without having to degrade my code I still could break only when false was returned.
So when I ran it the first break was in the third call:

So, thank god for such great tools like Visual Studio and ReSharper (R# hinted to me that I was doing something stupid in the first place)!