关于C#：如果使用else子句构造，则终止if有什么好处？

What is the benefit of terminating if … else if constructs with an else clause?

我们的组织有一个必需的编码规则(没有任何解释)，即：

if … else if constructs should be terminated with an else clause

例1：

1
2
3
4

if ( x < 0 )
{
x = 0;
} /* else not needed */

例2：

1
2
3
4
5
6
7
8
9
10
11
12

if ( x < 0 )
{
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
/* no change in value of x */
}

这是设计用来处理什么边缘情况的？

我也担心的是，示例1不需要else，但是示例2需要。如果原因是可重用性和可扩展性，我认为在这两种情况下都应该使用else。

相关讨论

也许可以问你的公司原因和利益。乍一看，它迫使程序员考虑它，并添加一条注释"不需要任何操作"。同样的推理(至少是有争议的)Java的检查异常。
你的意思是"如果"还是"如果"得到执行。您还希望执行其他部分。
示例2实际上是一个很好的示例，在该示例中，assert(false,"should never go here")可能有意义
@是的，我问过，也没有很好的答案，这就是我在StackOverflow中问的原因。在把问题放到这里之前，我也调查过这个问题，但没有找到任何合理的理由。
我们的组织有类似的规则，但并不是很精细。在我们的例子中，目的是双重的。首先，代码一致性。第二，没有松散的字符串/可读性。即使在不需要的情况下，如果需要其他代码，即使没有文档记录，也会增加代码的清晰度。我以前做过其他的事情，即使不需要，只是为了确保我已经在应用程序中解释了所有可能的结果。
如果有了if (x < 0) { x = 0; } else { if (y < 0) { x = 3; }}，你总是可以失败的。或者你也可以遵循这样的规则，其中很多都是愚蠢的，仅仅是因为你被要求这么做。
例2：如果x是1，它将转到其他，如果y是1，它将转到其他。理想情况下，如果x<0，x小于0，else if x>0，x大于0，则只测试相同的变量示例，否则x为0。
例如1：即使只看到一个没有else的if，初始化后的变量值已经是else语句了。示例：y="over 0"；如果x<0，则y="under 0"；打印y；-因此，如果x为-1，将在0下打印；如果x为1，将在0上打印。
因为不管你的代码有多好，你的需求是什么，总有一天其他的需求会被需要。在5年或10年内，它将发生，否则(或默认)将拯救你的生命。
@这不仅仅是检查异常，而是检查应取消检查的异常。
@Thilo assert(false,"should never go here")在Visual Studio 2015中导致警告C4002(宏参数太多)。我会用&&。IMHO C++ 11的EDOCX1，4增加了混淆。
我们在这里使用保护条款，所以…另外，它确实适用于非常具体的情况，建议避免
我确信我大约5年前回答了这个问题。
(答案是，如果你从不犯错，你就不需要它了。如果以后再也不编辑代码，则由另一个人来编辑。熟练的程序员在没有被命令的情况下这样做，因为他们知道(从经验中学习)这是一个好主意。)
@你能再回答一次吗？
@Thilo我有点晚了，但是仍然没有人发现这个错误：没有迹象表明其他的事情永远不会发生，只是它不应该有副作用(这在执行< 0检查时似乎是正常的)，这样断言就会使程序崩溃，因为在最常见的情况下，值可能在预期范围内。
@亚伦说得对，至少举例来说。示例二确实说"程序员希望永远不会达到这个目的"。不管是哪种方式，在那里拥有一些东西(甚至是按照公司编码风格的注释)是一件好事。

正如另一个答案中提到的，这是来自misra-c编码指南。其目的是防御性编程，这是一个经常用于关键任务编程的概念。

也就是说，每个if - else if必须以else结束，每个switch必须以default结束。

原因有两个：

自我记录代码。如果你写一个else，但不写，这意味着："我确实考虑过这样的情况：if和else if都不是真的。"
不写else意味着："要么我考虑了if和else if都不是真的情况，要么我完全忘了考虑，我的代码中可能有一个胖错误。"
停止失控代码。在任务关键型软件中，即使极不可能，您也需要编写健壮的程序。所以你可以看到代码

1
2
3
4
5
6
7
8
9
10
if (mybool == TRUE)
{
}
else if (mybool == FALSE)
{
}
else
{
// handle error
}

这段代码对于PC程序员和计算机科学家来说是完全陌生的，但对于任务关键型软件来说却是完全有意义的，因为它捕捉到了"mybool"因任何原因而腐败的情况。
历史上，您会担心由于EMI/噪声而导致RAM内存损坏。这在今天不是什么问题。更可能的是，内存损坏是由于代码中其他地方的错误造成的：指向错误位置的指针、数组越界错误、堆栈溢出、失控代码等。
因此，大多数时候，当您在实现阶段编写了错误时，像这样的代码会回来给自己一巴掌。这意味着它也可以用作调试技术：正在编写的程序告诉您何时编写了错误。

编辑

关于每一个单独的if后不需要else的原因：

if-else或if-else if-else完全覆盖了变量可以拥有的所有可能值。但是一个普通的if语句不一定能涵盖所有可能的值，它有一个更广泛的用途。大多数情况下，你只是想检查某个条件，如果不满足，就什么也不做。那么，编写用于覆盖else案例的防御编程就没有意义了。

另外，如果在每个if之后编写一个空的else，代码就会完全混乱。

MISRA-C:2012 15.7没有给出不需要else的理由，它只是说明：

Note: a final else statement is not required for a simple if
statement.

相关讨论

宇宙射线的攻击！(+ 1)
不幸的是，如果内存真的被破坏了，它不会命中else子句…执行比较时，它将导致运行时错误。
@纳尔逊。是的，不是，也许？这种假设是高度系统特定的。似乎您假设代码是从RAM执行的？对于任何嵌入式系统来说，从RAM运行代码都是一个很有问题的实践，不管它是否是关键任务。
如果内存损坏了，我希望它不仅会破坏mybool，还可能破坏检查代码本身。为什么不添加另一个块来验证您的if/else if/else是否按照预期编译？然后再验证一个以前的验证器？
当然，如果一个变量以某种方式"损坏"，那么比较将失败，或者它将根据使用的任何比较规则强制结果为真或假？
叹息。伙计们，如果除了桌面编程之外，你们绝对没有其他的经验，那就没有必要对一些你们显然没有经验的东西发表一目了然的评论。当讨论防御性编程时，PC程序员就会停下来。我添加了"这段代码对PC程序员来说完全陌生"的评论，这是有原因的。您不必为运行在基于RAM的台式计算机上的安全关键软件编程。时期。代码本身将驻留在带有ECC和/或CRC校验和的闪存ROM中。
好吧，我想编译器被禁止进行任何优化，因为否则它可能得出结论：mybool不能是TRUE或FALSE以外的任何东西。
@事实上，重复数据消除程序(除非mybool有一个非布尔类型，就像c得到自己的bool之前的情况一样；那么，如果没有额外的静态分析，编译器就不会做出假设)。关于"如果你写了一个else，但不写它"的主题，它意味着："无论是if还是else if都不是真的，我肯定考虑过这个场景。"：我的第一个反应是假设程序员忘记把代码放在else块中，否则为什么会有一个空的else块正好放在那里？一个// unused注释是适当的，而不仅仅是一个空块。
@这就是我在示例中使用"mybool"和"true/false"的原因，而不是使用bool、TRUE和FALSE。假设"mybool"是一些旧的、基于枚举或类似项的家庭brewn布尔类型。
@是的，如果没有代码，else块需要包含某种注释。空的else的常见做法是一个分号加上一个注释：else { ; // doesn't matter }。因为没有理由任何人只在自己的行上键入缩进的单分号。类似的做法有时也用于空循环：while(something) { ; // do nothing }。(显然，代码带有换行符。所以评论是不允许的)
@Lundin你有一个很好的答案，但是正如我在问题中提到的，为什么在示例1中不需要其他的答案。因为正如您所回答的(重点是示例2)，另一个是关于损坏的案例，并且示例1中的代码可以像示例2或嵌入式系统中的任何其他代码一样损坏，对吗？
@我试着用编辑来回答那个问题。
我要注意的是，这个带有两个ifs的示例代码甚至可以在多线程环境中的普通桌面软件中转到其他代码，因此mybool的值可以在两者之间进行更改。
@伦丁，谢谢，我正在调查更多的事情。关于腐败的案例，你能给我一篇已有的文章或科学信息来举例说明这一点吗("我的胸部"和"真的"和"假的"都不一样)？
@Lundin或者我应该为您的示例代码提出一个问题，也许人们可以展示许多其他案例可以涵盖的案例
@伦丁花时间调查后，我认为你的回答很好，我接受。但正如我在上面的评论中所说，我很高兴有文章能举例说明腐败案。
我强烈认为你确实需要最后一个。如果没有它，很容易有人在后面出现，monkey具有几个嵌套if语句的结构，并导致else语句变得不正确关联。
@JAB：更确切地说，更重要的是C有自己的_Bool，它是一种具有特定行为的类型，例如，分配给它的值被强制分配给0或1，而bool是中的宏，程序可以随意取消定义或重新定义。
是否有理由不将assert( false )放在空的else块中(如果合适)？这将记录它从未发生的预期，并有助于在调试时捕获错误。
@Raoulsteffen在安全关键软件中，您完全不允许在生产构建中保留任何调试代码。因此，像assert这样的事情将是有问题的。最好为实际产品实现错误处理程序，然后使用它。此外，assert在嵌入式系统中没有真正意义，因为通常没有"标准错误流"可用。
我希望assertfail()在嵌入式环境中设置重置pin。
@伦丁写道："没有理由有人会在一行上单独键入一个缩进的分号，"很久以前我就这么做了。只是半结肠？很明显，这意味着你不想在那里发生什么。"现在，我试着从树枝的圆括号里拿出一些东西，放到身体里。如果出于某种原因没有什么可以提取的，那么现在我将留下一个注释("；//什么都不做")。但这并不能改变我曾经做过的事情；所以，是的，我确实有一个原因，而且(不幸的是)我在遗留代码中留下了太多孤独的"；"实例。
@Lundin关于安全关键生产代码中的调试代码：这是引用的指南中建议的一部分，还是仅仅是与您合作的团队的意见？我以前使用过安全关键系统，并且认为我们还剩下调试代码。可能不在实际的安全关键部分，但在同一项目的其他部分——指南中是否有区别？
@Lundin虽然我知道你只是引用了一些指导原则，但你可能对这些指导原则不负任何责任：我一直觉得把内存损坏作为任何生产代码的一个原因是很愚蠢的(显然是缺少内存测试软件之类的东西)。我不认为这种检查是不必要的原因是您只检查内存的一小部分，只检查时间的一小部分。即使您确实有内存损坏，添加示例代码可能也无济于事。这几乎是一种错误的安全感。
@Aaron"没有调试代码"基本上意味着内部测试没有遗留问题。这被多种标准所禁止，不仅是misra-c。如果您实现了一个全面的错误处理程序系统，那当然是很好的，因为它是应用程序的一部分，而不是可能意外地在源代码中结束的东西。此外，如果所有操作都由同一个MCU执行，则不存在固件的"安全关键部分"。程序某一部分的错误可能导致另一部分失控。这意味着整个项目要么是安全关键的，要么不是，周期。
@Aaron或内存测试，答案提到："更可能的是，内存损坏是由于代码中其他地方的错误造成的：指向错误位置的指针、数组越界错误、堆栈溢出、失控代码等。"当然，在这些系统上，实际的代码总是从闪存而不是RAM执行。PC程序员不理解区别，因为他们总是将程序本身加载到RAM中，因此他们会"但是如果RAM损坏，您的程序可以执行任何无意义的操作代码"，这在执行NVM闪存代码的MCU上是不正确的。
@Lundin我很欣赏代码在哪里被执行的区别，但这仍然没有消除这样一个问题，即如果存在内存损坏，不管是什么原因(错误、严重的电磁干扰、蝴蝶效应、一个局部但微观的黑洞通过……无论如何)，示例if/else if/else检查仍然不太可能捕获它，即使它只是RAM中的变量数据。RAM中还有许多其他变量，其中许多变量在没有冗余内存的情况下很难检查是否损坏(ints、指针、float等)(这使得这种检查毫无意义)。
或者，作为一个类比，检查这个变量是因为它可能被破坏，当有那么多其他变量可能被破坏而没有被检测到时，就像安装一个摄像头来观察你面对棒球场的窗户，看窗户是否被破坏，但只安装一个这样的摄像头，并将其定位为只观察窗外的一个窗口。他有40扇面向公园的窗户，同样面临着危险。如果您真正关心的是内存损坏，足以检查它，那么就有一个多余的变量来检查它，因为这更可能捕获大多数形式的损坏。
@Aaron这可以追溯到RAM(包括MCU外围存储器映射寄存器)根本不可靠的时代。然后，它们必须从NVM中不断刷新。这种做法在某种程度上仍然是好的做法，因为NVM通常比RAM更可靠。但主要是为了检测错误和失控的代码。如果您曾经使用适当的错误处理程序实现适当的防御编程，那么您会注意到它有多好。因为最显著的效果是你自己的程序开始向你报告你自己的错误，通常是在设计阶段的早期。
让我们在聊天中继续讨论。

贵公司遵循misra编码指南。这些指导方针有几个版本包含了这条规则，但是来自misra-c:2004？：

Rule 14.10 (required): All if … else if constructs shall be terminated
with an else clause.

This rule applies whenever an if statement is followed by one or more
else if statements; the final else if shall be followed by an else
statement. In the case of a simple if statement then the else
statement need not be included. The requirement for a final else
statement is defensive programming. The else statement shall either
take appropriate action or contain a suitable comment as to why no
action is taken. This is consistent with the requirement to have a
final default clause in a switch statement. For example this code
is a simple if statement:

1
2
3
4
5
if ( x < 0 )
{
log_error(3);
x = 0;
} /* else not needed */

whereas the following code demonstrates an if, else if construct

1
2
3
4
5
6
7
8
9
10
11
12
13
if ( x < 0 )
{
log_error(3);
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
/* no change in value of x */
}

MISRA-C:2012取代了2004年版本，是新项目的最新建议，同样的规则也存在，但编号为15.7。

例1：在单个if语句中，程序员可能需要检查n个条件并执行单个操作。

1
2
3
4

if(condition_1 || condition_2 || ... condition_n)
{
//operation_1
}

在常规使用中，使用if时不需要一直执行操作。

例2：这里程序员检查n个条件并执行多个操作。在常规用法中，if..else if与switch类似，您可能需要执行类似于default的操作。因此，根据misra标准，需要使用else。

1
2
3
4
5
6
7
8
9
10
11
12
13

if(condition_1 || condition_2 || ... condition_n)
{
//operation_1
}
else if(condition_1 || condition_2 || ... condition_n)
{
//operation_2
}
....
else
{
//default cause
}

？这些出版物的当前和过去版本可通过misra webstore(via)购买。

相关讨论

谢谢，你的答案是所有内容的米斯拉规则，但我期待一个答案，我的困惑编辑部分的问题。
@我已经更新了我的答案，希望它能满足需要。
好答案。出于好奇，如果您希望else条款无法访问，那么这些指导者会说些什么呢？(不考虑最后的条件，可能会抛出一个错误？)
我将投票反对抄袭和侵犯版权的链接。我会编辑这篇文章，这样你的话和米斯拉的话就更清楚了。最初，这个答案只是一个原始的复制/粘贴。
@Lundin我接受这是Misra编码指南的复制/粘贴。检查问题的编辑和我的答案的编辑，这将使你更好地理解。最初问题为空，然后进行编辑。根据问题，我正在编辑我的答案。谢谢你的编辑
@Trieuthevan：问题不能是移动的目标。在你发帖之前，确保你的问题是完整的。
@T.J.Crowder我没有移动目标，我只是没有说够多，也没有说清楚我的困惑。谢谢提醒。
所以使用if(…) { … } else if(…) { … } else { /* meaningless comment */ }比使用if(…) { … } else if(…) { … } /* meaningless comment */ 好？
@JPMC26没有，但Misra的目的不是给你严格的代码，而是给你安全的代码。现在的任何编译器都会优化不可访问的代码，所以没有缺点。
我在misra网站上添加了一个文档描述的链接，以及一个说明从何处获取文档的脚注，这些文档可供购买。我自己没有文档的副本，因此无法添加页码或更多的节号，我认为所包含的规则号就足够了。CC @ Lundin
@Jasonc好吧，你再也不能买Misra-C:2004了，它被撤回了，取而代之的是Misra-C:2012。同样的规则也存在于2012年，但也有规则编号15.7。我们实际上不知道OP公司是在2004年还是2012年，但是引文是从2004年开始的。
@伦丁，我想你可以买。它被列为&163；10(pdf)或&163；40(硬拷贝)在商店页面上(大约向下1/3)，我刚刚添加数量1到我的篮子。不过，我并没有走得更远。它被标记为"仅供参考"，并注明被：2012取代。不知道公司使用的是哪一个版本，这是一个很好的观点；我会马上重新编辑答案，避免一些读者被误导。
@Jasonc Aha，甚至1998年的版本仍然可用。无论如何，强烈建议使用2012版本，因为它解决了许多问题，而且还支持C99。
我已经尽我所能地编辑了我先前评论中提到的内容。
@格雷厄姆，但我问的是关于安全代码的问题。他们是说在你期望无法访问的else块中抛出错误更安全，还是说放弃最后的条件检查更安全？
@jpmc26大多数misra-c不是为了抛出错误，而是为了使代码可读和可维护。最后一个"else"的要点是，如果错误出现在不应该出现的地方，就不要抛出错误(尽管你可以这样做)，而是明确地告诉你的评审者/维护者/同事你考虑过这个条件，而你并没有忘记它。所以说"永远不应该到这里"的评论不是很有用——那些评论应该说"永远不应该到这里是因为……"。
@JPMC26同样，就抛出错误而言，这取决于你不应该到达那里的原因。如果您不应该到达那里，因为根据上面的编译时条件，它确实是不可访问的，那么一条评论就可以了。如果由于该值有效但不应发生(例如，空指针检查)而不应该达到该值，那么释放肯定是有序的，因为当系统处于某种意外状态时，您不能期望系统正常地继续运行。你采取什么行动将取决于系统-电传有不同的故障保护要求从窗口。：)
非常好，谢谢。

This is the equivalent of requiring a default case in every switch.

这个额外的将减少程序的代码覆盖率。

在我将Linux内核或Android代码移植到不同平台的经验中，我们经常做一些错误的事情，在logcat中我们看到一些错误，比如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if ( x < 0 )
{
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
/* no change in value of x */
printk("
[function or module name]: this should never happen
");

/* It is always good to mention function/module name with the
logs. If you end up with"this should never happen" message
and the same message is used in many places in the software
it will be hard to track/debug.
*/
}

相关讨论

只是一个简短的解释，因为我在5年前就做了这一切。

在大多数语言中，不需要包含"空"的else语句(和不必要的{..}语句)，而在"简单的小程序"中则不需要。但是真正的程序员不会写"简单的小程序"，同样重要的是，他们也不会写那些会被使用一次然后被丢弃的程序。

当一个人写if/else时：

1
2
3
4

if(something)
doSomething;
else
doSomethingElse;

这一切看起来都很简单，甚至很难看出添加{..}的意义。

但从现在起的某一天，几个月后，另一个程序员(你永远不会犯这样的错误！)将需要"增强"程序，并将添加语句。

1
2
3
4
5

if(something)
doSomething;
else
doSomethingIForgot;
doSomethingElse;

突然，doSomethingElse有点忘了它应该在else的腿上。

所以你是一个很好的小程序员，你总是使用{..}。但是你写的是：

1
2
3
4
5

if(something) {
if(anotherThing) {
doSomething;
}
}

一切都很好，直到那个新来的孩子午夜修改：

1
2
3
4
5
6
7
8
9

if(something) {
if(!notMyThing) {
if(anotherThing) {
doSomething;
}
else {
dontDoAnything; // Because it's not my thing.
}}
}

是的，它的格式不正确，但是项目中的一半代码也是这样，"auto-formatter"被所有#ifdef语句搞混了。当然，真正的代码要比这个玩具例子复杂得多。

不幸的是(或不是)，我已经离开这类事情几年了，所以我没有一个新的"真实"的例子在头脑中——上面(显然)是人为的，有点矫揉造作。

这样做是为了使代码更易读，便于以后的引用，并向以后的审阅者清楚地表明，最后一个else处理的其余案例都是不做任何事情的，因此它们在第一眼就不会被忽略。

这是一个很好的编程实践，使代码可以重用和扩展。

我想添加到&ndash；中，部分与前面的答案相矛盾。虽然使用if-else是很常见的，如果以一种类似开关的方式使用if-else，它应该覆盖表达式的全部可思考值范围，但决不能保证完全覆盖任何可能的条件范围。关于switch构造本身也可以这样说，因此需要使用default子句，该子句捕获所有剩余值，如果无论如何都不需要，则可以将其用作断言保护。

这个问题本身有一个很好的反例：第二个条件根本不与x有关(这就是为什么我经常喜欢基于if的变量比基于switch的变量更灵活的原因)。从示例中可以明显看出，如果满足条件A，则X应设置为某个值。如果不满足A，则测试条件B。如果满足，那么x将收到另一个值。如果不满足a和b，则x应保持不变。

这里我们可以看到，应该使用一个空的else分支来评论程序员对读者的意图。

另一方面，我不明白为什么必须有一个else子句，特别是对于最新和最内部的if语句。在C语言中，没有"else if"这样的词。只有if和else。相反，根据Misra的说法，构造应该以这种方式正式缩进(我应该在它们自己的行上放置开放的花括号，但我不喜欢这样)：

1
2
3
4
5
6
7
8
9
10
11

if (A) {
// do something
}
else {
if (B) {
// do something else (no pun intended)
}
else {
// don't do anything here
}
}

当米斯拉要求在每根树枝上都加上花括号时，它会自相矛盾地提到"如果……Else if构造"。

任何人都可以想象，如果还有其他树的话，那么深巢树的丑陋之处，请看这里的旁注。现在假设这个构造可以任意扩展到任何地方。然后在最后要求一个else子句，而不是在其他任何地方，就变得荒谬了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if (A) {
if (B) {
// do something
}
// you could to something here
}
else {
// or here
if (B) { // or C?
// do something else (no pun intended)
}
else {
// don't do anything here, if you don't want to
}
// what if I wanted to do something here? I need brackets for that.
}

因此，我确信，制定《米斯拉指南》的人，会像其他人一样，考虑到自己的意图。

最后，他们要精确地定义"如果……else if构造"

基本原因可能是代码覆盖率和隐含的else：如果条件不是真的，代码将如何工作？对于真正的测试，您需要某种方法来查看您的测试条件是否为假。如果您已经通过了if子句的每个测试用例，那么您的代码在现实世界中可能会因为没有测试的条件而出现问题。

但是，有些条件可能与示例1类似，比如纳税申报表："如果结果小于0，则输入0。"您仍然需要在条件为假的情况下进行测试。

逻辑上，任何测试都意味着两个分支。如果它是真的，你做什么？如果它是假的，你做什么？

对于任何一个分支都没有功能的情况，可以添加一条关于为什么不需要功能的注释。

这可能对下一个维护程序员的到来有好处。他们不必搜索太远就可以决定代码是否正确。你可以预先猎杀大象。

就个人而言，它有助于我，因为它迫使我审视其他案例，并对其进行评估。这可能是一个不可能的条件，在这种情况下，我可能会因为违反合同而提出例外。它可能是良性的，在这种情况下，评论可能就足够了。

您的里程可能会有所不同。

大多数情况下，当您只有一个if声明时，这可能是以下原因之一：

功能保护检查
初始化选项
可选处理分支

例子

1
2
3
4
5
6

void print (char * text)
{
if (text == null) return; // guard check

printf(text);
}

但是当你做if .. else if的时候，这可能是一个原因，比如：

动态开关箱
加工叉
处理处理参数

如果你的if .. else if涵盖了所有的可能性，如果你的最后一个if (...)不需要，你可以去掉它，因为在那一点上，唯一可能的值就是那些条件所涵盖的值。

例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

int absolute_value (int n)
{
if (n == 0)
{
return 0;
}
else if (n > 0)
{
return n;
}
else /* if (n < 0) */ // redundant check
{
return (n * (-1));
}
}

在大多数这些原因中，有可能有些东西不适合您的if .. else if中的任何类别，因此需要在最后的else条款中处理它们，处理可以通过业务级过程、用户通知、内部错误机制等来完成。

例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#DEFINE SQRT_TWO 1.41421356237309504880
#DEFINE SQRT_THREE 1.73205080756887729352
#DEFINE SQRT_FIVE 2.23606797749978969641

double square_root (int n)
{
if (n > 5) return sqrt((double)n);
else if (n == 5) return SQRT_FIVE;
else if (n == 4) return 2.0;
else if (n == 3) return SQRT_THREE;
else if (n == 2) return SQRT_TWO;
else if (n == 1) return 1.0;
else if (n == 0) return 0.0;
else return sqrt(-1); // error handling
}

最后一个else条款与其他语言中的一些内容非常相似，如Java和C++，例如：

switch语句中的defaultcase
在所有特定的catch块之后出现的catch(...)。
try-catch子句中的finally。

嗯，我的例子涉及到未定义的行为，但有时有些人试图表现得花哨而失败，看看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

int a = 0;
bool b = true;
uint8_t* bPtr = (uint8_t*)&b;
*bPtr = 0xCC;
if(b == true)
{
a += 3;
}
else if(b == false)
{
a += 5;
}
else
{
exit(3);
}

你可能永远也不会期望拥有不是true或false的bool，但这可能发生。就我个人而言，我认为这是由决定做一些花哨事情的人引起的问题，但附加的else声明可以阻止任何进一步的问题。

我们的软件不是关键任务，但由于防御编程，我们也决定使用这个规则。我们在理论上无法访问的代码中添加了一个抛出异常(switch+if-else)。当软件快速失败时，它为我们节省了很多时间，例如，当一个新类型被添加时，我们忘记了更改一个或两个(如果有的话)或者切换。作为一个额外的好处，找到这个问题非常容易。

我目前正在使用PHP。创建注册表和登录表单。我只是纯粹使用if和else。没有其他不必要的。

如果用户单击提交按钮->它将转到下一个if语句…如果用户名少于"x"个字符，则发出警报。如果成功，请检查密码长度等。

如果这样做可以消除服务器加载时间检查所有额外代码的可靠性，则不需要像else这样的额外代码。