Question

I’m using gcc 4.7.0, in c89 mode.

I have this if-else statement and have 2 questions.

1. I am just wondering should I test for the FALSE or the TRUE conditions first. What is normally better. I know it doesn’t make much difference, but I am just wondering what other engineers do? In the example below I am checking for a FALSE first.

2. I always like to do some defensive programming. So I always if I can explicitly check each condition. for example rather than do if() – else. I would do if() – else if(). In the example below the condition can either be TRUE or FALSE. However, I always like to check the else condition to make sure that it is TRUE. Is there any real point to this?

Many thanks for any suggestions.

if(event->status == FALSE) {
    g_release_call_test(module, channel_id);
}
else if(event->status == TRUE) {
    if(UNIT_TEST & KARAOKE) {
        if(g_record_karaoke(module, channel_id) == FALSE) {
            g_release_call_test(module, channel_id);
        }
    }
    else if(UNIT_TEST & RECORD) {
        if(g_record_file_test(module, channel_id) == FALSE) {
            g_release_call_test(module, channel_id);
        }
    }
    else if(UNIT_TEST & GET_DIGITS) {
        if(g_collect_digits_test(module, channel_id) == FALSE) {
            g_release_call_test(module, channel_id);
        }
    }
}

Answer 1

First off, don’t do this for boolean values:

if (something == TRUE)
if (something == FALSE)

These should rather be something like:

if (something)
if (!something)

Boolean values should also be intelligently named so that the if statements read naturally, such as if (isFinished) or while (stillSomeMoreToGo). status is not a good name for a boolean unless it’s meant to indicate that something has a status and, even then, I’d use hasStatus or something similar.

In any case, something can be true in C even if it isn’t equal to your TRUE value. TRUE will be, by necessity, one value whereas C defines something as true if it’s non-zero (2³²-1 different possible values though of course that depends on your int specification).

Testing explicitly for true or false is a bad idea since all that does is generate another boolean, and where do you stop?

if ((event->status == TRUE) == TRUE) ...
if (((event->status == TRUE) == TRUE) == TRUE) ...
if ((((event->status == TRUE) == TRUE) == TRUE) == TRUE) ...
if (((((event->status == TRUE) == TRUE) == TRUE) == TRUE) == TRUE) ...

---

In terms of your specific questions, for (1), it probably won’t make one bit of difference from a performance point of view. However, sometimes it can affect code readability. Choose the method that gives you the “prettiest” code, and let the compiler sort out the best way to convert your source into native form.

The first thing I optimise for is readability, since that’s the thing that prevents most problems down the track. Once you profile the readable code and work out there’s a performance problem, then you can think about ways to improve.

But I’ll give you this advice for free: the most impressive improvements can usually be made at the macro level (things like algorithm selection and data structure choices), rather than at the micro level (testing for true or false, counting down instead of up in loops and so on).

For an example of readability, I tend to do short ones first (where the block inside the if is relatively concise). I also tend to do early returns first as well since they often reduce indentation. In other words, something like:

def fn (x):
    if (x < MIN_X_ALLOWED):
        return -1

    # Now carry on, knowing that x >= MIN_X_ALLOWED.

---

For (2), no, there’s no real point to this. You have explicitly decided that a boolean is needed and that only has two possible cases. You’re defending against an impossibility.

If it were an integer, and only the values 2, 3, 5, 7 and 11 were allowed, that would be different since you’d want to defend against (for example) the value 10.