实际上，我发现自己不得不使用goto，因为我真的想不出更好(更快)的方法来编写这段代码:

我有一个复杂的对象，我需要对它做一些操作。如果对象处于一种状态，那么我就可以进行快速操作，否则我就必须进行慢速操作。问题是，在某些情况下，在缓慢的手术过程中，可能会意识到这可以用快速手术来完成。

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

这是一个实时UI代码的速度关键部分，所以我真的认为GOTO在这里是合理的。

Hugo

Go To可以在某些情况下为“真正的”异常处理提供一种替代品。考虑:

ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;

显然，这段代码被简化了，以占用更少的空间，所以不要太纠结于细节。但是考虑一下我在产品代码中多次看到的另一种选择，即程序员为了避免使用goto而费尽心机:

success=false;
do {
    ptr = malloc(size);
    if (!ptr) break;
    bytes_in = read(f_in,ptr,size);
    if (count=<0) break;
    bytes_out = write(f_out,ptr,bytes_in);
    if (bytes_out != bytes_in) break;
    success = true;
} while (false);

现在这段代码在功能上做了完全相同的事情。事实上，编译器生成的代码几乎完全相同。然而，在程序员对Nogoto(可怕的学术指责之神)的热情中，这个程序员完全打破了while循环所代表的底层习惯，并对代码的可读性造成了实质性的影响。这样也好不到哪里去。

所以，这个故事的寓意是，如果你发现自己为了避免使用goto而求助于一些非常愚蠢的事情，那么就不要这样做。

我们已经讨论过这个问题了，我坚持我的观点。

此外，我受够了人们将高级语言结构描述为“伪装的goto”，因为他们显然根本没有抓住重点。例如:

即使Scheme中先进的连续控制结构也可以被描述为复杂的后向。

那完全是胡说八道。每个控制结构都可以在goto方面实现，但这个观察完全是微不足道和无用的。Goto被认为是有害的，因为它的积极影响，而是因为它的消极后果，这些已经被结构化编程消除了。

Similarly, saying “GOTO is a tool, and as all tools, it can be used and abused” is completely off the mark. No modern construction worker would use a rock and claim it “is a tool.” Rocks have been replaced by hammers. goto has been replaced by control structures. If the construction worker were stranded in the wild without a hammer, of course he would use a rock instead. If a programmer has to use an inferior programming language that doesn't have feature X, well, of course she may have to use goto instead. But if she uses it anywhere else instead of the appropriate language feature she clearly hasn't understood the language properly and uses it wrongly. It's really as simple as that.

我避免使用它，因为同事/经理无疑会在代码评审或偶然发现它时质疑它的使用。虽然我认为它有一些用途(例如错误处理案例)，但你会遇到一些其他开发人员，他们会遇到一些类型的问题。

这不值得。

因为goto可以用于令人困惑的元编程

Goto既是高级控件表达式，也是低级控件表达式，因此它没有适合大多数问题的合适设计模式。

它是低级的，因为goto是一个基本操作，它实现了一些高级操作，比如while或foreach之类的。

从某种意义上说，它是高级的，当以某种方式使用时，它将以一种清晰的顺序执行的代码，以一种不间断的方式(除了结构化循环)，并将其转换为逻辑片段，这些逻辑片段有足够的gotos，可以动态地重新组装逻辑。

所以，有平淡的一面，也有邪恶的一面。

平淡的一面是，一个向上指向的goto可以实现一个完全合理的循环，而一个向下指向的goto可以执行一个完全合理的中断或返回。当然，实际的while、break或return语句可读性更强，因为可怜的人不需要为了了解全局而模拟goto语句的效果。总的来说，这是个坏主意。

The evil side involves a routine not using goto for while, break, or return, but using it for what's called spaghetti logic. In this case the goto-happy developer is constructing pieces of code out of a maze of goto's, and the only way to understand it is to simulate it mentally as a whole, a terribly tiring task when there are many goto's. I mean, imagine the trouble of evaluating code where the else is not precisely an inverse of the if, where nested ifs might allow in some things that were rejected by the outer if, etc, etc.

Finally, to really cover the subject, we should note that essentially all early languages except Algol initially made only single statements subject to their versions of if-then-else. So, the only way to do a conditional block was to goto around it using an inverse conditional. Insane, I know, but I've read some old specs. Remember that the first computers were programmed in binary machine code so I suppose any kind of an HLL was a lifesaver; I guess they weren't too picky about exactly what HLL features they got.

说了这么多，我曾经在我写的每个程序中都加了一个go，“只是为了惹恼那些纯粹主义者”。

我只需要它在基本(即。VB, VBScript等)和批处理文件。然后我只将它用于错误处理。在Basic中，我倾向于只使用“on error goto”。在批处理文件中，我必须使用它，因为没有其他命令。然后，我只使用它们作为向前跳转到有意义的标签。