The credibility of the break statement

I had recently read in a book that using the break statement in say e.g. for loops is considered inelegant (although it is widely accepted for use in the switch statement).

开发者_如何转开发

What is the reason for this "accusation"?

Should I use a break statement in a for loop, or should I use multiple conditions?

---

You'll have to ask the author of the book (which book?), since my ESP is on the fritz today^{[citation needed]}.

Sometimes^[when?] it's said that, if you write lots of break statements throughout your code body, then it's no longer easy to see the loop invariants and the control flow without performing a detailed program analysis.

But, realistically, a couple of break statements inside conditional blocks isn't going to hurt anyone, and complicating loop conditionals is, IMO, more immediately prone to going horribly wrong.

---

The reasoning is that it's clearer to have the condition for continuing or exiting the loop in one place rather than scattered throughout the body of the loop.

---

This is like those who say goto is bad because of a paper Djikstra wrote on the subject in the 60's. When used liberally, I would agree. But for instance, in a C-function, which doesn't have the benefit of C++'s exception handling using try and catch, the deliberate and intentional use of goto can be very helpful in creating a self-contained clean-up section in case of an error return for a function that allocates memory using malloc(). Without the goto statement, you would have to place clean-up code at the end of every if statement that detected an error. For instance, what looks better to you ... this:

int my_func()
{
    int* a = malloc(10);

    //... some code
    if (some_error)
    {
        free(a);
        return -1;
    }

    //... more code

    if (some_other_error)
    {
        free(a);
        return -1;
    }

    //... more code

    if (another_error)
    {
        free(a);
        return -1;
    }

    //... more code

    free(a);
    return 0;
}

or code that looks like this:

void my_func()
{
    int* a = malloc(10);

    //... some code

    if (some_error)
        goto return_error;

    //... more code

    if (some_other_error)
        goto return_error;

    //... more code

    if (another_error)
        goto return_error;

    //... more code

    normal_return:
        free(a);
        return 0;

    return_error:
        free(a);
        return -1;
}

With the first example, every time you changed something, you would have to manage all the error returns in each of the if-statement blocks. The latter approach gives you a nice self-contained clean-up section. So the same is true with other arbitrary rules for syntax like "don't use break in a loop" ... if it helps increase the code's maintainability, reliability, and readability, by all means use it.

---

It's a matter of style.
There would be people who say it breaks the flow of the loop ( Just like you shouldn't use multiple return statements in a method).

But a break is very expressive. Properly placed breaks can be much more readable and maintainable than a loop condition that includes the state in which we should stop the loop (instead of the breaks).

---

I am not sure if it helps, but, Joaquín M López Muñoz addressed this question in his blog: http://bannalia.blogspot.com/2009/03/about-break-statements.html

Regards, &rzej