40

我的强迫症让我在编写 case 语句时添加“中断”，即使它们不会被执行。考虑以下代码示例：

switch(option) {
    case 1:
        a = 1;
        b = 7;
        break;
    case 2:
        a = 2;
        b = 4;
        return (-1);
        break;
    default:
        a = -1;
        break;
}

我的两个问题是：
对于“案例 2：”，我真的不需要休息，但无论如何让它在那里是个好主意吗？对于“默认：”。是纯粹的强迫症，还是有任何真正的理由在这里休息？

4

13 回答 13

36

你不需要休息，但拥有它们并没有什么坏处。在我看来，保持你的代码结构化是值得的。

于 2009-06-05T17:17:12.900 回答
26

我同意在最后的默认情况下休息，不同意退货后休息。（一位同事这样做，这伤害了我的眼睛。）

我还缩进开关以减少缩进级别的扩散。：） IE：

switch(option) {
case 1:
    a = 1;
    b = 7;
    break;
case 2:
    a = 2;
    b = 4;
    return -1;
default:
    a = -1;
    break;
}

（我还认为，由于 return 语句不是一个函数，因此不适合强制执行一种使其看起来像一个多余的样式。）

于 2009-06-05T17:21:09.010 回答
8

默认情况下的休息只是个人喜好问题。

回来后休息一下对我来说几乎是矛盾的。我会删除中断，只是为了让 return 语句真正脱颖而出。

于 2009-06-05T17:18:50.620 回答
2

我认为返回后的中断是错误的形式，您会收到有关某些编译器上无法访问代码的警告。

默认情况下的中断是完全合适的，情况下降是一种工具，使用时应特别标记。

于 2009-06-05T17:21:50.697 回答
2

我更喜欢在每种情况下都休息一下，包括默认值，并避免在switch内部进行 return 。对于只有 2-3 个 case（包括默认值）的短开关，返回是可以的，但前提是所有case都以相同的方式进行。“毫无意义”的休息我认为毫无意义，只会让它有更多的代码可读。空的默认值也是如此，只是打破，完全没有意义。在我看来，易于阅读代码比如果有人碰巧改变这个或那个会发生什么更重要。

于 2009-06-05T18:42:13.750 回答
1

休息对你没有任何帮助，但也没有伤害。

就个人而言，如果我有返回值，我通常会将它们排除在外——但如果可能的话，我也会尽量避免在一个函数中有多个返回点。

但是，我确实认为这种default:情况下的中断是好的 - 原因之一：如果您将其省略，并且有人在默认情况下添加了一个新的情况：，如果他们“忘记”添加中断，则行为会有所不同.

于 2009-06-05T17:19:54.347 回答
1

正如其他人指出的那样，在返回或默认情况下休息主要是个人风格问题。

当我不必遵循任何特定的样式规则时，我更喜欢这样的东西：

    开关（富）{
         案例0：
             巴兹 = 1;
             休息;
         情况1：
             酒吧 %= 2;
             返回-1；
             /* 还没到 */
         案例2：
             酒吧 = -1;
             返回-2；
             /* 还没到 */
             休息;
         默认：
             休息;
    }

在情况 1 和 2 之间，我倾向于选择 2。即使注释说 NOTREACHED，当代码更改时，注释也可能会撒谎（当然是无意的）。我喜欢 NOTREACHED 评论，因为它可以让 lint 知道您知道自己在做什么，并提醒您提前退出该功能。如果退货被删除，那么在退货后休息会减少错误的推理对我来说似乎是有缺陷的。无论您是否进入下一个案例，或者您退出开关并像以前一样继续，您仍然会得到虚假行为。

当然，如果我可以避免它，我不会从开关体内的函数返回。

于 2009-06-05T18:27:00.750 回答
1

有人告诉我，在 C、C++、java 和 C# 中，如果你不放置这些“中断”，程序代码流将落入其他“案例”并执行其中的指令，无论变量是否'没有分配给“案例”的值。

于 2009-06-05T22:34:38.117 回答
1

关于其他人发表的评论，他们将中断保留在默认情况下，以防有人稍后出现并在其后添加一个情况：在我工作的地方，编码标准说始终将默认情况作为最后一种情况；所以在我们的情况下，打破这种情况只是多余的。（这是我完全同意公司编码标准的一种情况，因为默认情况总是最后一个，即使在很长的 switch 语句中，你也总是知道在哪里找到它。）

As for breaks after returns, I tend to omit the break unless there are any execution paths that do not return, as I find it redundant. (My exception to this is, on the rare occasions when there are several execution paths in a case and I can't tell with a quick scan of the code whether or not they all return, then I'll leave the break in just to be safe.)

于 2009-06-06T00:29:21.550 回答
0

我个人没有设置中断，但是当其他人决定将返回 (-1) 移到开关之外并忘记添加中断时，它可能会有所帮助。

于 2009-06-05T17:16:38.703 回答
0

我会插入以表明您不打算进入下一个案例。

于 2009-06-05T17:21:38.840 回答
0

在这个确切的例子中，对于这两个问题，这是个人偏好。一般来说，规则是这样的：任何没有中断的事情都会失败。这意味着（正如 Pod 所说）在默认情况下设置中断是一个好主意，以防它们不是最后的。这也意味着如果您的案例包含退货，那么接下来的休息确实是没有必要的。

于 2009-06-05T21:39:49.333 回答
-1

请原谅我的知识有限，但什么是强迫症？
除此之外，Brian Kernighan对何时应该（不）在语句中使用提供了很好的解释。breakswitch

于 2009-06-05T17:25:41.127 回答