是否使用goto？

Question

这个问题可能听起来很陈词滥调，但我在这里的情况。

当我开始写代码时，我意识到如果我使用标签来标记不同的状态，并在情况发生时使用goto从一个状态跳到另一个状态，代码可能会更具可读性。

在这种情况下，使用标准的中断和标志变量非常麻烦，而且很难跟踪状态。

哪种方法更好？最重要的是，我担心这可能会给我的老板留下不好的印象，因为我正在实习。

Answer 1

使用goto实现状态机通常很有意义。如果您真的担心使用goto，一个合理的替代方案通常是使用一个修改过的state变量和一个基于该变量的switch语句：

typedef enum {s0,s1,s2,s3,s4,...,sn,sexit} state;

state nextstate;
int done = 0;

nextstate = s0;  /* set up to start with the first state */
while(!done)
   switch(nextstate)
      {
         case s0:
            nextstate = do_state_0();
            break;
         case s1:
            nextstate = do_state_1();
            break;
         case s2:
            nextstate = do_state_2();
            break;
         case s3:
             .
             .
             .
             .
         case sn:
            nextstate = do_state_n();
            break;
         case sexit:
            done = TRUE;
            break;
         default:
            /*  some sort of unknown state */
            break;
      }

Answer 2

goto本身并没有什么问题。它们通常被认为是“禁忌”的原因是因为一些程序员(通常来自汇编界)使用它们来创建几乎不可能理解的“意大利面”代码。如果您可以在保持代码整洁、可读性和无bug的同时使用goto语句，那么您将获得更大的动力。

为每个状态使用goto语句和一段代码绝对是编写状态机的一种方式。另一种方法是创建一个保存当前状态的变量，并使用switch语句(或类似语句)根据状态变量的值选择要执行的代码块。使用第二种方法查看Aidan Cully的答案，以获得一个好的模板。

实际上，这两种方法非常相似。如果使用状态变量方法编写状态机并对其进行编译，则生成的程序集可能与使用goto方法编写的代码非常相似(取决于编译器的优化级别)。goto方法可以看作是从状态变量方法中优化出额外的变量和循环。你使用哪种方法是个人选择的问题，只要你能写出可以工作的、可读的代码，我希望你的老板不会因为你使用一种方法而对你产生任何不同的看法。

如果您要将此代码添加到已包含状态机的现有代码库中，我建议您遵循已在使用的任何约定。

Answer 3

如果我想给老板留下好印象，我会使用有限状态机生成器，比如Ragel。

这种方法的主要好处是，您能够在更高的抽象级别上描述您的状态机，而不需要关心自己是使用goto还是一个switch。更不用说在Ragel的特殊情况下，您可以自动获得FSM的漂亮图表，在任何点插入操作，自动最小化状态数量和各种其他好处。我有没有提到生成的FSM也非常快？

缺点是它们更难调试(自动化可视化在这里很有帮助)，而且您需要学习一个新工具(如果您有一台简单的机器，而且您不太可能经常编写机器，这可能不值得)。