“ break”和“ continue”是不好的编程习惯吗？

 function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}
 

 while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}
 

#1 楼

在块的开头使用时，首先进行检查，它们就像前提条件一样，所以很好。

在块的中间使用，周围有一些代码，它们的作用就像隐藏的陷阱，所以不好。

#2 楼

您可以阅读Donald Knuth在1974年发表的论文《结构化编程》中的“转到语句”，其中他讨论了go to在结构上理想的各种用法。它们包括break和continue语句的等效项（其中go to的许多用法已开发成更为有限的构造）。

（这些示例引起了我的兴趣。通常，喜欢任何代码的一个入口和一个出口的人都不喜欢break和continue，并且这种人也对多个return语句不满意。）

#3 楼

我不认为他们是坏人。它们不好的想法来自结构化编程的时代。与以下概念有关：函数必须具有单个入口点和单个出口点，即。 e。每个功能仅一个return。

如果您的函数很长，并且有多个嵌套循环，那么这很有道理。但是，您的函数应该简短，并且应该将循环及其主体包装成它们自己的简短函数。通常，强制一个函数具有单个退出点可能会导致逻辑混乱。

如果函数很短，则只有一个循环，或者最糟糕的是有两个嵌套循环，并且循环体很短，那么很清楚break或continue的作用。同样清楚的是，有多个return语句是做什么的。

这些问题在Robert C. Martin的“清理代码”和Martin Fowler的“重构”中得到了解决。

#4 楼

糟糕的程序员讲的是绝对的（就像Sith一样）。优秀的程序员可能会使用最清晰的解决方案（在所有其他条件不变的情况下）。

频繁使用break和continue会使代码难以遵循。但是，如果替换它们使代码更加难于遵循，那将是一个糟糕的更改。

您给出的示例肯定是一种情况，其中断断续续应替换为更优雅的内容。

#5 楼

大多数人认为这是个坏主意，因为这种行为不容易预测。如果您正在阅读代码，并且看到while(x < 1000){}，则假定它将一直运行到x> = 1000为止。但是如果中间有中断，那将不成立，因此您无法真正信任您循环播放...

这是人们不喜欢GOTO的相同原因：当然，它可以很好地使用，但它也可能导致令人讨厌的意大利面条式代码，该代码从部分随机跳转到另一部分。部分。

对于我自己来说，如果我要执行一个在多个条件下中断的循环，我会执行while(x){}，然后在需要中断时将X切换为false。最终结果将是相同的，并且阅读该代码的任何人都将更仔细地研究改变X值的事物。

#6 楼

是的，您可以[重新]编写没有break语句的程序（或从循环中间执行相同操作的返回值）。但是您可能必须引入其他变量和/或代码重复，这通常会使程序更难以理解。因此，Pascal（编程语言）非常糟糕，特别是对于初学者而言。您的老板基本上希望您使用Pascal的控制结构进行编程。如果Linus Torvalds穿上你的鞋子，他可能会向你的老板展示中指！

有一个计算机科学的结果叫做Kosaraju的控制结构层次，可以追溯到1973年，在Knuth的著作中提到（更多）关于1974年的goto的著名论文。（顺便说一下，David Thornley已经在上面推荐了Knuth的论文。）S. Rao Kosaraju在1973年证明的是，不可能重写所有具有多级程序的程序将深度n中断到中断深度小于n的程序中，而不会引入额外的变量。但是，可以说这仅仅是一个理论上的结果。 （只需添加一些额外的变量？！您肯定可以这样做来取悦您的老板...）

从软件工程的角度来看，更重要的是Eric S于1995年发表的最新论文。罗伯茨（Roberts）题为“循环退出与结构化编程：重新开始辩论”（http://cs.stanford.edu/people/eroberts/papers/SIGCSE-1995/LoopExits.pdf）。罗伯茨总结了他之前其他人进行的一些实证研究。例如，当一组CS101型学生被要求为实现在数组中顺序搜索的函数编写代码时，研究的作者对使用中断/返回/跳转来退出找到元素时的顺序搜索循环：


我还没有找到一个使用[此样式]尝试编写程序的人，该人产生了错误的解决方案。


Roberts还说：


试图解决问题而未使用for循环的显式返回的学生的情况要差得多：在尝试该策略的42名学生中，只有七名设法产生了正确的解决方案。该数字表示成功率不到20％。


是的，您可能比CS101的学生更有经验，但无需使用break语句（或等效地从中途返回/转到循环），最终您将编写代码，尽管名义上结构良好，但在额外的逻辑变量和代码重复方面足够多，有人（可能是您自己）会在尝试遵循老板的编码风格时在其中放入逻辑错误。

我还要在这里说，罗伯茨的论文对于普通程序员来说更容易获得，因此比Knuth的论文读起来更好。它也更短，涵盖了一个狭窄的主题。您甚至可以向老板推荐它，即使他是管理层而不是CS类型。

#7 楼

我不考虑使用这两种不良做法中的任何一种，但是在同一个循环中使用过多它们应该重新考虑在循环中使用的逻辑。谨慎使用。

#8 楼

您给出的示例不需要中断也无需继续：

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

我对示例中的4行的“问题”是它们都在同一水平上，但是他们做了不同的事情：有些休息，一些继续...您必须阅读每一行。

在我的嵌套方法中，您越深入，代码就变得越“有用”。

但是，如果深入到内部，您会发现停止循环的原因（除主要条件之外），则可以使用中断或返回。我宁愿使用在顶级条件下测试的额外标志，也不愿使用它。中断/返回更直接；它比设置另一个变量更好地说明了意图。

#9 楼

“坏处”取决于您如何使用它们。通常，只有在循环构造会为我节省无法通过算法重构保存的循环时，才使用中断。例如，循环遍历一个集合以查找具有特定属性值设置为true的项目。如果您只需要知道其中一个项目将此属性设置为true，那么一旦达到该结果，就可以适当地中断以终止循环。

如果使用break不会使代码特别易于阅读，缩短运行时间或以显着方式节省处理周期，那么最好不要使用它们。我倾向于尽可能使用“最低公分母”进行编码，以确保跟随我的任何人都可以轻松查看我的代码并弄清楚发生了什么（我并不总是成功的）。休息减少了，因为它们确实引入了奇数的进/出点。被滥用时，它们的行为可能非常像不合常规的“ goto”语句。

#10 楼

绝对不是...是，使用goto是不好的，因为它会破坏程序的结构，并且很难理解控制流。

但是使用break和continue这样的语句绝对是这些天是必需的，根本不被认为是不好的编程习惯。

也不难理解使用break和continue时的控制流程。在类似switch的结构中，绝对需要break语句。

#11 楼

基本概念来自能够对程序进行语义分析。如果您只有一个入口和一个出口，则表示可能状态的数学要比管理分支路径容易得多。

在一定程度上，这一困难反映出在概念上能够做到的问题。您的代码的原因。

坦白说，您的第二个代码并不明显。到底在做什么是继续“继续”，还是“下一步”循环？我不知道。至少您的第一个例子很清楚。

#12 楼

我会用

 while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}
 

代替您的第二个代码片段-出于简洁的原因-我实际上认为这更容易阅读，并且可以让别人了解正在发生的事情。一般而言，循环的条件应完全包含在循环的条件下，而不是在整个身体中乱扔。但是，在某些情况下，break和continue可以提高可读性。 break比continue多，我可能会加上：D

#13 楼

我不同意你的老板。在适当的地方可以使用break和continue。实际上，将理解和异常处理引入现代编程语言的原因是，仅使用structured techniques并不能解决所有问题。

在旁注
我不想在这里开始进行宗教讨论，但您可以将代码的结构重组为更具可读性，例如：

 while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}
 

另一方面，我个人不喜欢在条件条件中使用( flag == true )，因为如果变量已经是布尔值，那么您将引入一个额外的比较，当布尔值时需要进行比较拥有您想要的答案-除非您当然可以确定编译器将优化额外的比较。

#14 楼

我同意你的老板。它们之所以不好是因为它们产生的方法具有很高的环复杂性。这种方法难以阅读且难以测试。幸运的是，有一个简单的解决方案。将循环体提取到单独的方法中，其中“继续”变为“返回”。 “ Return”更好，因为“ return”结束之后-不必担心本地状态。

对于“ break”，将循环本身提取到一个单独的方法中，将“ break”替换为“ return” ”。

如果提取的方法需要大量参数，则表明提取一个类-将它们收集到上下文对象中。

#15 楼

我认为这是一个深深嵌套在多个循环中的问题。很难知道您要进入哪个循环。继续执行可能也很困难，但是我认为真正的痛苦来自于中断-逻辑可能难以遵循。

#16 楼

只要不像下面的示例那样将它们用作伪装的goto：

 do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);
 

我对他们很好。 （示例在生产代码中显示），

#17 楼

我不喜欢这两种风格。这就是我想要的：

 function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}
 

我真的不喜欢使用return中止功能。感觉像是滥用return一样。

使用break也不总是很容易阅读。

更好的可能是：

 notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}
 

更少的嵌套和将复杂的条件重构为变量（显然，在实际程序中，您必须具有更好的名称...）

（以上所有代码均为伪代码）

#18 楼

否。这是解决问题的一种方法，还有其他解决方法。

当前许多主流语言（Java，.NET（C＃+ VB），PHP，编写自己的语言）都使用“中断”和“继续”以跳过循环。它们都是“结构化的goto”句子。

没有它们：

 String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");
 

和他们在一起：

 String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());
 

请注意，“ break”和“ continue”代码较短，通常将“ while”语句转换为“ for”或“ foreach”语句。

两种情况都与编码风格有关。我不想使用它们，因为冗长的样式使我可以更好地控制代码。

我实际上是在某些项目中工作的，在这些项目中必须使用这些句子。

一些开发人员可能认为，如果我们不得不删除这些句子，则不一定是必要的，而是假设的它们，我们还必须删除“ while”和“ do while”（“直到您重复，直到重复”）；-)

结论，即使我不想使用它们，我也认为一个选择，不是不好的编程习惯。

#19 楼

我原则上不反对continue和break，但是我认为它们是非常底层的结构，通常可以用更好的东西来代替。

我在这里以C＃为例，考虑要迭代一个集合的情况，但是我们只希望满足某些谓词的元素，并且我们最多只希望进行100次迭代。

 for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}
 

这看上去很干净。这不是很难理解。我认为从声明性的角度来看会有所收获。将它与以下内容进行比较：

 foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);
 

也许“ Where and Take”调用甚至不应该用这种方法。也许应该在将集合传递给此方法之前完成此过滤。无论如何，通过远离低级内容，而将更多的精力放在实际的业务逻辑上，可以更加清楚地了解我们真正感兴趣的内容。将我们的代码分成更能遵循良好设计规范的内聚模块变得更加容易，因此上。

代码的某些部分中仍然会存在低级内容，但是我们希望尽可能地将其隐藏起来，因为需要花大量精力来进行业务推理。问题。

#20 楼

我只引用代码完成：

在循环的顶部使用Continue进行测试。继续的一个很好的用法是在顶部测试条件之后将执行移到循环的主体之外。例如，如果循环读取记录，丢弃一种记录并处理另一种记录，则可以在循环的顶部进行这样的测试。
以这种方式继续使用可以避免if测试这将有效地缩进循环的整个主体。另一方面，如果继续发生在循环的中间或结尾，请使用和代替。

#21 楼

Code Complete在关于使用goto和例程或循环中的多个返回的内容中有一个不错的部分。

一般来说，这不是一个坏习惯。 break或continue准确说明下一步会发生什么。
我也同意。

Steve McConnell（代码完成作者）使用了几乎与您相同的示例来展示使用各种goto语句的优势。

但是过度使用break或continue可能会导致软件复杂且无法维护。