Question

我最近在一本书中读到过使用break声明，例如for循环被认为是不优雅的（虽然它被广泛接受用于switch语句）。

这种“指责”的原因是什么？

我应该在break循环中使用for语句，还是应该使用多个条件？

Answer 1

你将不得不问这本书的作者（哪个书？），因为我今天的ESP正在讨论^{[citation needed] < / SUP>}

有时^[when？]据说，如果你在整个代码体中写了很多break语句，那么就不再容易看到循环不变量和控制流，而不执行详细的程序分析。

但是，实际上，条件块中的一些break语句不会伤害任何人，并且使循环条件复杂化，IMO，更容易出现going horribly wrong。

Answer 2

理由是，在一个地方继续或退出循环而不是分散在整个循环体中的条件更清楚。

Answer 3

这就像那些说goto因为一篇关于60年代这个主题的文章所写的那样糟糕的人。如果大量使用，我会同意。但是，例如，在C函数中，使用try和catch没有C ++异常处理的好处，故意和有意使用goto可能非常有用。如果使用malloc()分配内存的函数返回错误，则创建一个自包含的清理部分。如果没有goto语句，则必须在检测到错误的每个if语句的末尾放置清理代码。例如，你看起来更好......这个：

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;
}

或代码如下：

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;
}

使用第一个示例，每次更改内容时，都必须管理每个if语句块中的所有错误返回。后一种方法为您提供了一个很好的独立清理部分。所以对于语法的其他任意规则也是如此，例如“不要在循环中使用break”......如果它有助于提高代码的可维护性，可靠性和可读性，那么一定要使用它。

Answer 4

这是一种风格问题会有人说它打破了循环的流程（就像你不应该在方法中使用多个return语句）。

但break非常富有表现力。正确放置的断点比包含我们应该停止循环的状态（而不是断点）的循环条件更具可读性和可维护性。

Answer 5

我不确定它是否有帮助，但是，JoaquínMLópezMuñoz在他的博客中解决了这个问题： http://bannalia.blogspot.com/2009/03/about-break-statements.html

此致＆安培; rzej

break语句的可信度

5 个答案: