在我的第一次代码评审中(不久前)，有人告诉我，在所有switch语句中包含一个default子句是一种很好的实践。我最近想起了这个建议，但不记得理由是什么了。现在我听起来很奇怪。
是否有一个合理的理由总是包含默认语句? 这是语言依赖吗?我不记得当时我在用什么语言了——也许这适用于一些语言而不是其他语言?
当前回答
switch语句应该总是包含一个默认子句吗? 不存在缺省情况下的开关情况，在缺省情况下，当不匹配任何其他case值时，将触发开关值开关(x)。
其他回答
如果你知道switch语句只有一组严格定义的标签或值，那么就这样做，以覆盖基础，这样你总是会得到有效的结果。只需将默认值放在标签之上，从编程/逻辑上来说，它将是其他值的最佳处理程序。
switch(ResponseValue)
{
default:
case No:
return false;
case Yes;
return true;
}
一些(过时的)指南是这么说的，比如MISRA C:
最后一个默认子句的要求是防御性编程。该条款应采取适当的行动，或包含关于为什么不采取行动的适当评论。
这个建议已经过时了，因为它不是基于目前的相关标准。明显的疏漏是哈兰·卡斯勒说的
省略默认大小写允许编译器在看到未处理的大小写时选择性地发出警告或失败。静态可验证性毕竟比任何动态检查都要好，因此当您也需要动态检查时，这种牺牲是不值得的。
正如Harlan还演示的那样，在切换之后可以重新创建与默认情况相同的功能。当每个情况都是早期返回时，这是微不足道的。
从广义上讲，动态检查的典型需求是输入处理。如果一个值来自程序控制之外，它就不可信。
这也是Misra采取极端防御性编程立场的地方，即只要一个无效值在物理上是可表示的，就必须检查它，无论程序是否可证明是正确的。如果软件需要在出现硬件错误时尽可能地可靠，这是有意义的。但正如Ophir Yoktan所说，大多数软件最好不要“处理”错误。后一种做法有时被称为进攻性编程。
switch语句应该总是包含一个默认子句吗? 不存在缺省情况下的开关情况，在缺省情况下，当不匹配任何其他case值时，将触发开关值开关(x)。
在不真正需要的时候使用默认子句是防御性编程 这通常导致代码过于复杂，因为有太多的错误处理代码。 这种错误处理和检测代码损害了代码的可读性，使维护更加困难，并最终导致比解决更多的错误。
因此，我认为如果不应该达到默认值—您不必添加它。
注意，“不应该达到”意味着如果达到了，这是软件中的一个错误——你确实需要测试可能包含不需要的值的值，因为用户输入等等。
我会说这取决于语言，但在C中，如果你要打开一个枚举类型并处理每个可能的值，最好不要包含默认大小写。这样，如果您稍后添加了一个额外的enum标记，并且忘记将其添加到交换机中，称职的编译器将会就缺少的大小写向您发出警告。
