这证明goto语句合理吗？

一秒钟前，我遇到了这个问题，我从中提出了一些建议：“ break n”结构有名称吗？

对于人们来说，这是一种不必要的复杂方法，它可以指示程序摆脱双重嵌套的for循环：

for (i = 0; i < 10; i++) {
    bool broken = false;
    for (j = 10; j > 0; j--) {
        if (j == i) {
            broken = true;
            break;
        }
    }
    if (broken)
        break;
}

我知道教科书喜欢说goto语句是魔鬼，而我本人一点也不喜欢它们，但这是否有例外的理由？

我正在寻找与n嵌套for循环有关的答案。

注意：无论您回答是，否还是介于两者之间，都不欢迎完全封闭的答案。特别是如果答案是否定的，请提供一个合理的正当理由（无论如何，这与Stack Exchange法规相距不远）。

显然需要go-to语句是因为您为循环选择了不良的条件表达式。

您声明自己希望外循环继续到i < 10，而最内循环继续到j > 0。

但是实际上，这并不是您想要的，您只是没有告诉循环您要让他们评估的真实条件，而是想要使用break或goto来解决它。

如果您告诉循环您的真实意图是从开始的，则无需中断或转到。

bool alsoThis = true;
for (i = 0; i < 10 && alsoThis; i++)
{    
    for (j = 10; j > 0 && alsoThis; j--)
    {
        if (j == i)
        {
            alsoThis = false;
        }
    }
}

在这种情况下，您可以将代码重构为一个单独的例程，然后仅从return内部循环中进行重构。这样就不需要打破外部循环了：

bool isBroken() {
    for (i = 0; i < 10; i++)
        for (j = 10; j > 0; j--)
            if (j == i) return true;

    return false;
}

不，我认为没有goto必要。如果您这样写：

bool broken = false;
saved_i = 0;
for (i = 0; i < 10 && !broken; i++)
{
    broken = false;
    for (j = 10; j > 0 && !broken; j--)
    {
        if (j == i)
        {
            broken = true;
            saved_i = i;
        }
    }
}

有&&!broken两个回路可以让你打破这两个循环的时候了i==j。

对我而言，这种方法更可取。循环条件非常清楚：i<10 && !broken。

可以在这里看到工作版本：http : //rextester.com/KFMH48414

码：

public static void main(String args[])
{
    int i=0;
    int j=0;
    boolean broken = false;
    for (i = 0; i < 10 && !broken; i++)
    {
        broken = false;
        for (j = 10; j > 0 && !broken; j--)
        {
            if (j == i)
            {
                broken = true;
                System.out.println("loop breaks when i==j=="+i);
            }
        }
    }
    System.out.println(i);
    System.out.println(j);
}

输出：

当i == j == 1时循环中断
2
0

简短的回答是“取决于”。我主张选择有关代码的可读性和可理解性。转到方法可能比调整条件更清晰，反之亦然。您可能还会考虑到最少惊奇原则，商店/项目中使用的准则以及代码库的一致性。例如，goto离开开关或进行错误处理是Linux内核代码库中的常见做法。还要注意，有些程序员可能在阅读您的代码时遇到问题（要么因为“ goto is evil”而提出，要么由于老师的想法而没有学到），其中一些甚至可能“判断您”。

一般来说，goto在相同功能中走得更远通常是可以接受的，尤其是在跳转不太长的情况下。您留下一个嵌套循环的用例是“不太邪恶” goto的已知示例之一。

在您的情况下，goto足以使它看起来很诱人，但并没有多大改进，因此值得违反在代码库中使用它们的规则。

想想您将来的审稿人：他/他将不得不考虑：“这个人是一个不好的编码员，还是实际上这是goto值得的情况？让我花5分钟的时间自行决定或研究互联网。” 当您不能完全使用goto时，为什么要对将来的编码器执行此操作？

通常，这种心态适用于所有“不良”代码，甚至可以对其进行定义：如果它现在可以工作，并且在这种情况下是好的，但是会努力验证其正确性，在这个时代，goto总是会这样做，然后就不这样做了。做吧。

话虽这么说，是的，您制作了其中一个较为棘手的案件。你可以：

• 使用更复杂的控制结构（例如布尔标志）打破两个循环
• 将内部循环放入自己的例程中（可能是理想的）
• 将两个循环都放到例程中，然后返回而不是中断

对于我来说，很难创建一个双循环不太紧密的情况，以至于无论如何它都不应该成为自己的例行程序。

顺便说一下，我所见过的对此的最佳讨论是Steve McConnell的Code Complete。如果您喜欢批判性地考虑这些问题，我强烈建议您阅读，甚至涵盖所有内容，尽管它非常庞大。

TLD; DR：没有具体说明，一般是

对于您使用的特定示例，出于许多其他原因指出的相同原因，我会拒绝。您可以轻松地将代码重构为等效的良好形式，从而无需使用goto。

一般来说取缔打击goto的基础上的理解性质普遍性goto和使用它的成本。软件工程的一部分是制定实施决策。这些决定的合理性是通过权衡成本与收益之间的关系而实现的，只要收益大于成本，就可以实施。由于成本和收益的不同估值而引起争议。

关键是，总是存在a goto被证明是合理的例外，但是仅因某些原因而存在不同的估值。可惜的是，许多工程师只是出于故意的无知而将技术排除在外，因为他们是在互联网上阅读技术，而不是花时间去理解原因。

我认为这种情况并不能说明一个例外，因为可以这样写：

def outerLoop(){
    for (i = 0; i < 10; i++) {
        if( broken?(i) )
          return; // broken
    }
}

def broken?(i){
   for (j = 10; j > 0; j--) {
        if (j == i) {
            return true; // broken
        }
   }
   return false; // not broken
}