Question

我的问题基本上都在标题中。我没有真正的应用程序，我只是想确保我使用普遍接受的良好编码实践，并且我记得我的CS教授说在可能的情况下通常会避免休息，但他从未告诉我们为什么。< / em>的

我会自己问他，但今年夏天他不在办公室。

Answer 1

这是一个神学问题。那些反对使用break（或继续使用break）的人说它会使程序的控制流更难以遵循，从而使程序的可读性降低。但是，制作可读代码的更简单方法就是简化函数，使用有意义的变量名，适当地评论等等。

Answer 2

有时候教授是错的。

他可能会反对从中间跳出一个循环。这类似于在函数中使用return语句......有些人认为这是亵渎神灵。

什么是最简单的，并且生成最容易维护的代码，应该是应该使用的。

Answer 3

一般来说，当满足某个条件时（例如，当你找到了你正在寻找的东西时，等等），你会使用'break'来摆脱周期;我不认为它是“邪恶的”，如臭名昭着的GOTO声明，但合理的人会有所不同。

Answer 4

Dijkstra所说的对goto语句有害 - http://drdobbs.com/blogs/cpp/228700940

和https://softwareengineering.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices

Answer 5

你的教授说“应该避免休息”，因为它们与现在禁忌的goto语句类似。然而，说“应尽可能避免休息”是错误的。

为了便于阅读，存在休息。你可以随心所欲地做任何事情，但这并不意味着你应该做。有时候做一个像“在这种情况下，摆脱这个循环”的陈述是有道理的。或“在这种情况下，从此功能返回。”

在嵌套for循环中使用break来实现程序流是一个坏主意，这种方式可能会给随意的读者带来一些困惑。

简单的经验法则：在这里使用break（而不是额外的if / thens，另一个布尔值等）是否更容易理解或更难理解？就这么简单。

Answer 6

让你的教授尝试用任何C风格的语言写一个switch语句而不会中断。我可以做到这一点，但结果代码将不再具有可读性。

switch (someExpression) {
    case enumVar.CaseA:
        // do things here, but don't you dare break!
    case enumVar.CaseB:
        // do other things - possibly unrelated or contradictory to CaseA

    // ... and so on
}

什么时候适合休息？

6 个答案: