The C# code-base I work on has hundreds of places where I have felt a boolean expression could have been used to simplify the code substantially.

Here’s an example of what I mean:

if (someBoolValue && someOtherBoolValue)
{
    return true;
}
else
{
    return false;
}

This is frustrating ‘over-coding’ to my mind because as we will see, there is a dramatically shorter way to express this:

return someBoolValue && someOtherBoolValue;

Essentially, as far as the language is concerned, anywhere that you can use a boolean is a place where you can use a boolean expression (I am paraphrasing here).

By reducing our code in this way, we have not lost anything; in my example both values in the expression are properties or members, so in debug mode we can still make the mouse over the text to see what the value of that field is.

What About Functions?

We can do precisely the same with functions that return a boolean. For example:

return someFunction() && someOtherFunction();

However, as in a recent Eric Lippert post Style Follows Semantics, we do introduce a risk here. What if someFunction() or someOtherFunction() have side-effects? He proposes that the short-hand expression approach should only be used where it is safe to compute a value.

In this example, he prefers the long-hand:

bool loginSuccessful;
if (NetworkAvailable())
    loginSuccessful= LogUserOn();
else
    loginSuccessful= false;

where we can put a break-point on the LogUserOn statement, and having it stand alone helps to demonstrate that it is an important functional element of the code.

Meanwhile, he prefers the shorter notation for this example:

bool canUseCloud = NetworkAvailable() && UserHasFreeSpaceInCloud();

where neither of the NetworkAvailable() or UserHasFreeSpaceInCloud() have side-effects.

Special Cases for Returns

So, it is perfectly acceptable stylistically to do this:

return NetworkAvailable() && UserHasFreeSpaceInCloud();

…but in this case (and perhaps others) it may sometimes be preferable to do this:

bool result = NetworkAvailable() && UserHasFreeSpaceInCloud();
return result;

In this case, we introduce the holding variable not as an optimisation, but to make it simpler to find out the result of A() && B() in debug mode. By having the holding variable we can simply find out it’s value by holding the mouse over the text.

A Little Sojourn to Unix Shell Scripts

10+ years ago I was working in a role where we used shell-scripting a lot. There, we used an idiom that produced shorter code as we have seen above, but in an entirely inappropriate way.

Here’s an extract from my notes:

command1 && command2  # Execute command2 if command1 
                      #  completes successfully (return code of 0)
command1 || command2  # Execute command2 if command1 fails

The implication of my notes is precisely that we were using the side-effects of boolean algebra to introduce control-flow. This may have been (and may still be for all I know) an acceptable meme to use in scripting languages… but I would suggest is inappropriate to use in a language like C# with an IDE, for the same reasons that are suggested above.

As ever, correctness should be our first goal, and if it is semantically more correct to use code that happens to take up a little bit more of the page, then do so 🙂 otherwise the shorter version should be used because there is simply less to read.