Switch语句掉线…应该允许吗？[关闭]

只要我记得我就避免使用switch语句掉线。实际上，我不记得它曾经作为一种可能的方式进入我的意识，因为它早在我的脑海中就被深深钻研了，它只不过是switch语句中的一个错误。但是，今天我遇到了一些设计上使用它的代码，这让我立即想知道社区中的每个人对switch语句失败的看法。

是某种编程语言应该明确不允许的（就像C＃一样，尽管它提供了一种解决方法），或者它是任何一种功能强大的语言的功能，都足以让程序员掌握？

编辑： 我对落空的含义还不够具体。我经常使用这种类型：

    switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something
            break;
        case 2:
        case 3:
        case 4:
            // Do something
            break;
   }

但是，我担心这样的事情。

   switch(m_loadAnimSubCt){
        case 0:
        case 1:
            // Do something, but fall through to the other cases
            // after doing it.

        case 2:
        case 3:
        case 4:
            // Do something else.
            break;
   }

这样，只要大小写为0、1，它将在switch语句中执行所有操作。我从设计上就已经看到了这一点，但我不知道是否同意以这种方式使用switch语句。我认为第一个代码示例非常有用且安全。第二个似乎有点危险。

这可能取决于您认为的失败之处。我对这种事情还可以：

switch (value)
{
  case 0:
    result = ZERO_DIGIT;
    break;

  case 1:
  case 3:
  case 5:
  case 7:
  case 9:
     result = ODD_DIGIT;
     break;

  case 2:
  case 4:
  case 6:
  case 8:
     result = EVEN_DIGIT;
     break;
}

但是，如果您有一个case标签，后跟代码进入另一个case标签，那么我几乎总是认为这很糟糕。也许将通用代码移至函数并从两个地方调用将是一个更好的主意。

并且请注意，我使用“邪恶”的C ++常见问题解答定义

这是一把双刃剑。它有时非常有用，但通常很危险。

什么时候好？当您希望10个案件都以相同的方式处理时...

switch (c) {
  case 1:
  case 2:
            ... Do some of the work ...
            /* FALLTHROUGH */
  case 17:
            ... Do something ...
            break;
  case 5:
  case 43:
            ... Do something else ...
            break;
}

我喜欢的一条规则是，如果您想做任何想排除中断的事情，则需要明确注释/ * FALLTHROUGH * /以表明您的意图。

您听说过达夫的装置吗？这是使用开关故障的一个很好的例子。

与几乎所有语言功能一样，它是可以使用且可以被滥用的功能。

根据您正在执行的操作，失败确实是一件方便的事情。考虑以下简洁明了的方式来安排选项：

switch ($someoption) {
  case 'a':
  case 'b':
  case 'c':
    // Do something
    break;

  case 'd':
  case 'e':
    // Do something else
    break;
}

想象一下使用if / else这样做。真是一团糟。

几次它可能非常有用，但是一般而言，理想的行为是不会掉队。应该允许失败，但不能隐含。

一个示例，用于更新某些数据的旧版本：

switch (version) {
    case 1:
        // Update some stuff
    case 2:
        // Update more stuff
    case 3:
        // Update even more stuff
    case 4:
        // And so on
}

我希望为开关中的后备使用不同的语法，例如errr ..

switch(myParam)
{
  case 0 or 1 or 2:
    // Do something;
    break;
  case 3 or 4:
    // Do something else;
    break;
}

注意：如果您使用标志在枚举中声明所有情况，对枚举已经可以实现，对吗？听起来也不错。这些案例很可能已经（应该？）已经成为您枚举的一部分。

对于使用扩展方法的流畅接口来说，这可能是个好案例（无双关语）？有点像...

int value = 10;
value.Switch()
  .Case(() => { /* Do something; */ }, new {0, 1, 2})
  .Case(() => { /* Do something else */ } new {3, 4})
  .Default(() => { /* Do the default case; */ });

虽然那可能甚至更难读：P

与任何事物一样：如果谨慎使用，它可能是一个优雅的工具。

但是，我认为这些弊端足以证明不使用它，最终不再允许它（C＃）。问题包括：

• 忘记休息很容易
• 对于代码维护者而言，并非总是显而易见的是故意省略了中断

充分利用开关/外壳掉线：

switch (x)
{
case 1:
case 2:
case 3:
 Do something
 break;
}

Baaaaad使用交换机/案例掉线：

switch (x)
{
case 1:
    Some code
case 2:
    Some more code
case 3:
    Even more code
    break;
}

我认为可以使用if / else构造来重写它，而不会造成任何损失。

我的最后一句话：避免在糟糕的示例中使用掉落式案例标签，除非您维护使用和理解这种样式的旧代码。

它既强大又危险。失败的最大问题是它并不明确。例如，如果您遇到频繁编辑的代码，但这些代码带有切换功能，那么您如何知道这是故意的却不是错误？

无论在任何地方使用它，我都确保对其进行正确评论：

switch($var) {
    case 'first':
        // Fall-through
    case 'second':
        i++;
        break;
 }

像在第一个示例中那样使用穿透功能显然是可以的，我认为这不是真正的穿透功能。

第二个示例很危险，并且（如果没有广泛评论）则很不明显。我教我的学生不要使用这样的构造，除非他们认为值得为它添加注释框，这说明这是一个故意的失败，以及为什么这种解决方案比替代方案更好的原因。这不鼓励随意使用，但在有利的情况下仍然允许使用。

当有人想违反编码标准时，这或多或少相当于我们在太空项目中所做的：他们必须申请豁免（我被要求就该裁决提供建议）。

我不喜欢自己的switch陈述-太容易出错并且很难阅读。唯一的例外是当多个case语句都执行完全相同的操作时。

如果某个switch语句的多个分支要使用某些通用代码，我会将其提取到一个单独的通用函数中，该函数可以在任何分支中调用。

在某些情况下，使用穿透是程序员的懒惰行为-他们可以使用一系列||。举例来说，这些语句使用一系列“全部捕获”切换用例。

话虽如此，当我知道最终我仍然需要这些选项（例如，在菜单响应中）但还没有实现所有选择时，我发现它们特别有用。同样，如果您同时对'a'和'A'进行穿透，则我发现使用开关穿透比使用复合if语句实质上更清洁。

这可能是风格和程序员的想法问题，但是我通常不喜欢以“安全”的名义删除语言的组成部分，这就是为什么我倾向于使用C及其变体/后代而不是说， Java。我喜欢能够与指针之类的东西相处，即使我没有“理由”。

仅当将直通用作代码块的跳转表时，才应使用直通。如果在更多案例之前代码的任何部分都无条件中断，则所有案例组都应以这种方式结束。

其他都是“邪恶的”。