使用“break”打破“for”循环被认为是有害的？

Question

前几天我开始了一个快速的开源项目，当有些伙伴查看svn上的代码时，其中一个人告诉我在break循环中使用for语句被认为是有害的不应该这样做。

但他补充说，我会在Linux内核源代码的break循环中找到几个for语句，但这只是因为只有Linus Torvalds和Chuck Norris被允许使用它而且没有其他人。

你怎么看？我认为在break循环中使用for没有问题。在我看来，使用布尔变量或类似的东西模拟break的行为会增加很多不必要的开销，并使代码不那么简单。

此外，没有与goto进行比较的余地，因为break无法随意将程序的流量从一个点改为另一个谎言goto。

Answer 1

我认为使用休息没有问题。总是存在你想要停止处理循环的情况，并且使用break;比将循环计数器设置为使循环停止的值更有意义（并使其更具可读性！）下一次迭代。

Answer 2

强制性：

关键是你不应该纯粹基于不良做法（或快速变速器）来避免它，而是根据具体情况考虑。

一切都与清晰度有关。正如你所说，你永远不必使用它，但在某些情况下它会提高可读性。当循环通常正常终止时它很有用，但在极少数情况下你必须摆脱困境。通常（或总是）破坏的循环更多的是代码气味（但仍然可能是合适的）。

Answer 3

使用break不仅没有问题，我会说有人说这被认为是“有害的”是彻头彻尾的错误。

break是用于中止循环的语言功能 - 您可以使用goto，但随后您会产生下面XKCD漫画的（适当的）愤怒。您可以在条件中使用标志，但这会妨碍可读性。 break不仅是最简单的，也是最常见的方式，可以多次摆脱循环。按照意图使用它。

---

编辑：为了更深入地了解这里：当你编写代码时，“我应该使用语言特征X或Y”的指导原则应该是“哪种方式会导致更优雅的代码“？在代码中，优雅几乎是一门艺术，但我将它放在可读性和算法（读取：不是微优化）效率之间的平衡。可读性将取决于代码的长度，复杂性等。单行boost :: bind可能更难以阅读＆amp;理解比3线循环。

如果语言功能可以帮助您编写在完成工作时更容易理解的代码，那么请使用它。这适用于break，goto，C ++例外等。不要盲目跟随“X是（邪恶|被认为有害）” - 每次都应用常识和逻辑。

Answer 4

break不仅没有问题，break不足时也是OK to use goto。也不要害怕多重回报。

以上所有内容仅适用于使代码更易于理解*。

*如果您的PHB允许...

Answer 5

我认为你的伴侣很疯狂。 break完全可以接受，完全可读，并且完全可维护。周期。

Answer 6

有一个范例，任何循环应该只有一个退出点（与函数相同应该只有一个返回）。这与可读性有关。退出点太多会使代码难以理解。此外，如果您想要进行代码验证（例如，如果您的代码是正确的，则数学证明）非常重要。

但是，指南往往有所帮助，但并不严格。在某种情况下，休息比不使用休息更好。因此，人们应该务必这样做，但要理解这些原则的原因，以便创造出良好的代码。

Answer 7

我认为这取决于背景。虽然在某些情况下它可能是“糟糕”的编码风格，但我不能想到它会有害的情况。

事实上，在某些情况下我会推荐它。例如，如果您使用线性搜索，任何情况（最坏的情况除外），break会提高您的速度。我认为当您使用时会突破循环发现你的针头是完全可以接受的，并且它比使用循环变量（可能不仅仅用于循环，取决于你的程序）或将循环体包裹在if块中更具可读性。 （另一个选项，包含if的{​​{1}}，结合了两个世界中最糟糕的一个：在continue块中包装循环逻辑，而像你这样的人抨击糟糕的编码风格不喜欢if的朋友。）

Answer 8

增加循环计数器而不是使用break也意味着你完成了循环的当前迭代，这可能是也可能不是。
if子句中，然后在您意识到需要检查是否要多次停止循环时再次执行此操作，并且您将很快意识到为什么人们使用{{ 1}}

Answer 9

如果您正在考虑使用给定的技术，我建议使用此算法。

• 如果被视为良好做法：
  • 使用它。
• 如果不被视为良好做法：
  • 只有在您认为它是最佳的长期解决方案时才使用它。
• 如果被视为邪恶：
  • 只有在您认为它是最佳的长期解决方案时才使用它，并且您对自己的判断非常有信心。要注意：被认为是邪恶的东西往往具有欺骗性的吸引力。

我会将break;归类为“不良做法”。在使代码更具可读性，减少错误的可能性，不会使调试复杂化等时使用它。