switch(type)
{
case 1:
//something
case 2:
//something else
default:
// unknown type! based on the language,
// there should probably be some error-handling
// here, maybe an exception
}
variable = (variable == "value") ? 1 : 2;
switch(variable)
{
case 1:
// something
case 2:
// something else
default:
// will NOT execute because of the line preceding the switch.
}
enum SomeEnum
{
ENUM_1,
ENUM_2,
// More ENUM values may be added in future
};
int foo(SomeEnum value)
{
switch (value)
{
case ENUM_1:
return 1;
case ENUM_2:
return 2;
}
// handle invalid values here
return 0;
}
5
在我的公司,我们为航空电子和国防市场编写软件,我们总是包含一个默认语句,因为必须明确处理switch语句中的所有情况(即使它只是一个评论说“什么也不做”) . 我们无法承受软件只是行为不端或只是意外崩溃(甚至是我们认为不可能的) Value .
可以讨论的是,默认情况并不总是必要的,但是总是要求它,我们的代码分析器可以很容易地检查它 .
4
"switch"语句是否应始终包含默认子句?不应该 . 它通常应该包括默认值 .
包含默认子句只有在有事情要做的情况下才有意义,例如断言错误条件或提供默认行为 . 包括一个“只是因为”是货物崇拜节目并没有提供任何 Value . 它的“开关”相当于说所有“if”语句都应该包含“else” .
switch ( x ){
case 0 : { - - - -}
case 1 : { - - - -}
}
/* What happens if case 2 arises and there is a pointer
* initialization to be made in the cases . In such a case ,
* we can end up with a NULL dereference */
19 回答
我会说这取决于语言,但在C中,如果你打开一个枚举类型并且你处理每一个可能的值,你最好不要包括一个默认情况 . 这样,如果您稍后添加额外的枚举标记并忘记将其添加到交换机,那么合格的编译器会向您发出有关丢失案例的警告 .
在不需要的情况下使用默认子句是Defensive programming这通常导致代码过于复杂,因为错误处理代码太多 . 这种错误处理和检测代码损害了代码的可读性,使维护更加困难,并最终导致比它解决的更多错误 .
所以我相信如果不应该达到默认值 - 你不必添加它 .
请注意,“不应该达到”意味着如果它达到了软件中的错误 - 您需要测试由于用户输入等而可能包含不需要的值的值 .
切换案例应该几乎总是有一个
default
案例 .Reasons to use a default
1.到'catch'意外的值
2.处理'default'诉讼,案件是针对特殊行为的 .
您在菜单驱动的程序和bash shell脚本中看到了很多 . 当变量在switch-case之外声明但未初始化时,您可能也会看到这一点,并且每个case都将其初始化为不同的值 . 这里默认需要初始化它,以便访问变量的行代码不会引发错误 .
3.要向某人阅读您已经涵盖该案例的代码 .
这是一个过于简化的例子,但重点是有人阅读代码时不应该想知道为什么
variable
不能是1或2以外的东西 .我能想到的唯一一个不使用
default
的情况是当交换机正在检查某些东西时,其中很明显的其他替代方案可以被高兴地忽略没有 .
如果没有默认操作,上下文很重要 . 如果你只关心几个 Value 观会怎么样?
以读取游戏的按键为例
添加:
只是浪费时间并且无缘无故地增加代码的复杂性 .
无论你使用什么语言,我都会使用默认子句 .
事情可以而且确实出错了 . Value 观将不是您所期望的,依此类推 .
不想包含默认子句意味着您确信您知道可能的值集 . 如果您认为您知道可能值的集合,那么,如果该值超出了这组可能的值,您将希望被告知它 - 这肯定是一个错误 .
这就是为什么你应该总是使用default子句并抛出错误的原因,例如在Java中:
没有理由包含更多信息而不仅仅是“无法访问”的字符串;如果确实发生了这种情况,那么无论如何你都需要查看变量等的源和值,并且异常堆栈跟踪将包含该行号,因此不需要浪费时间将更多文本写入异常消息 .
没有默认情况在某些情况下实际上可能是有益的 .
如果您的switch case是枚举值,没有默认情况,如果您缺少任何案例,则可以收到编译器警告 . 这样,如果将来添加新的枚举值并且您忘记在交换机中添加这些值的大小写,则可以在编译时找到有关该问题的信息 . 如果将无效值强制转换为枚举类型,您仍应确保代码对未处理的值采取适当的操作 . 因此,对于可以在枚举情况下返回而不是中断的简单情况,这可能最有效 .
在我的公司,我们为航空电子和国防市场编写软件,我们总是包含一个默认语句,因为必须明确处理switch语句中的所有情况(即使它只是一个评论说“什么也不做”) . 我们无法承受软件只是行为不端或只是意外崩溃(甚至是我们认为不可能的) Value .
可以讨论的是,默认情况并不总是必要的,但是总是要求它,我们的代码分析器可以很容易地检查它 .
"switch"语句是否应始终包含默认子句?不应该 . 它通常应该包括默认值 .
包含默认子句只有在有事情要做的情况下才有意义,例如断言错误条件或提供默认行为 . 包括一个“只是因为”是货物崇拜节目并没有提供任何 Value . 它的“开关”相当于说所有“if”语句都应该包含“else” .
这是一个无关紧要的例子:
这相当于:
据我所知,答案是“默认”是可选的,说开关必须始终包含默认值就像说每个'if-elseif'必须包含'其他' . 如果默认情况下存在逻辑,那么'default'语句应该在那里,否则代码可以继续执行而不做任何事情 .
如果你知道switch语句只有一组严格定义的标签或值,那么只需要这样做就可以覆盖基础,这样你就可以获得有效的结果 . 只需将默认值放在标签上,即可以编程/逻辑方式是其他 Value 观的最佳处理者 .
至少它在Java中不是强制性的 . 根据JLS的说法,它说最多可以出现一个默认情况 . 这意味着没有默认情况可以接受 . 它有时还取决于您使用switch语句的上下文 . 例如,在Java中,以下开关块不需要默认情况
但是在下面的方法中,它希望返回一个String,默认情况下很方便,以避免编译错误
虽然你可以通过在最后只有一个return语句来避免上述方法的编译错误而没有默认情况,但是提供默认情况会使它更具可读性 .
您应该有一个默认值来捕获未预期的值 .
但是,我不同意Adrian Smith的说法,你的默认错误信息应该是毫无意义的 . 可能有一个未经处理的案例,你没有预见(这有点重要),你的用户最终会看到,像“无法访问”这样的消息完全没有意义,并且在这种情况下无助于任何人 .
一个很好的例子,你有多少次有一个完全没有意义的BSOD?或致命异常@ 0x352FBB3C32342?
如果开关值( switch(variable ))无法达到默认情况,则根本不需要默认情况 . 即使我们保留默认情况,它也完全没有执行 . 这是死代码 .
它是一个可选的编码“惯例” . 根据用途,是否需要它 . 我个人认为,如果你不需要它,它不应该在那里 . 为什么要包含用户不会使用或达不到的内容?
如果案例可能性有限(即布尔值),那么默认子句是 redundant !
如果
switch
语句中没有默认情况,如果在某个时间点出现该情况,则该行为可能是不可预测的,这在开发阶段是不可预测的 . 包含default
案例是一种很好的做法 .这样的做法可能导致像NULL取消引用,内存泄漏以及其他类型的严重错误这样的错误 .
例如,我们假设每个条件初始化一个指针 . 但是如果出现
default
情况并且如果我们在这种情况下没有初始化,那么就有可能使用空指针异常登陆 . 因此,建议使用default
case语句,即使它可能是微不足道的 .因为MISRA C这样说:
也就是说,对于大多数软件,我建议不要使用MISRA C:
特别是
取决于特定语言中的开关如何工作,但是在大多数语言中,如果没有匹配的情况,则执行会在没有警告的情况下通过switch语句进行 . 想象一下,你期望一些值并在switch中处理它们,但是你在输入中得到了另一个值 . 什么都没发生,你什么都不知道 . 如果你在默认情况下发现了这个案例,你就会知道出现了问题 .
在枚举使用的开关中可能不需要默认情况 . 当switch包含所有值时,默认情况永远不会执行 . 所以在这种情况下,没有必要 .
switch语句是否应该包含默认子句?在没有默认情况下,没有开关情况可以存在,在开关情况下,默认情况下将触发开关值
switch(x)
,在这种情况下x与任何其他情况值不匹配时 .