是否应根据案件的稀有性或处理困难来安排陈述？

在我现在正在编写的一些代码中，我有类似以下内容：

if (uncommon_condition) {
    do_something_simple();
} else {
    do();
    something();
    long();
    and();
    complicated();
}

我的一部分认为“编写的方式很好。应该先处理简单的案例，然后再处理更复杂的案例。” 但是另一部分说：“不！else代码应该放在之下if，因为它if是用于处理异常情况，else并且用于处理所有其他情况。” 哪个是正确的或更可取的？

通过其执行可能性的顺序。最常见，最可能等的条件应优先考虑。

“处理它们的困难”应通过代码结构，抽象等处理。在示例中，else块可以重构为单个方法调用。您希望if子句处于相同的抽象级别。

if ( ! LotteryWinner ) {
    GoToWorkMonday();
} else {
    PlanYearLongVacation();
}

尝试增强可读性。一种方法是将较长的代码块放入其他部分。

if (s == null)
     // short code
else 
     // long 
     // code
     // block

比

if (s != null)
    // long
    // code
    // block
else
    // short code

我没有听说过这样的固定规则，但我遵循这样

if(usual)
{
(more often)
}
else (unusual)
{
(rarely occurring)
}

但是，如果两者都具有相同的功能，但属性不同，那么最好先处理不寻常的问题，然后再处理常规问题，这样您就可以保存一条指令。

if(x == 0)  // 1
  {x = 1;}  // 2
else
  {x = 2;}  // 3

对于以上代码，汇编代码将如下所示：

1. 000d 837DFC00        cmpl    $0, -4(%ebp)
   0011 7509            jne .L2

2. 0013 C745FC01        movl    $1, -4(%ebp)
   001a EB07            jmp .L3

    .L2:
3.001c C745FC02         movl    $2, -4(%ebp)

        .L3:

如果内部条件为true，则流量为1-> 2（4个指令）
如果内部条件为false，则流量为1-> 3（3个指令）

因此最好将异常或很少发生的事件置于部分正常条件下，否则我们每次可以保存一条指令；-)

我发现完全相反的模式导致更容易阅读代码，并减少或消除了嵌套的if语句。我将其称为“手套”模式。（在讲故事，一战书将是一系列具有完成最后的任务之前要成功满足挑战）通过处理您的优势情况下第一，你让你的代码的主体是干净简洁：

if(gauntlet_1){ handle the first gauntlet condition }; 
if(gauntlet_2){ handle the second gauntlet condition };
...
// All preconditions (gauntlets) have been successfully handled

// Perform your main task here

对我来说，更多的是条件，而不是它们执行的代码的复杂性。您需要对条件进行排序，以便先捕获异常条件，然后再捕获更常见的条件。另外，如果else代码真的很长而且很复杂，我可能会为此做一个子程序，以使条件部分对读者显而易见。

我没有固定的规则，但通常我会遵循此规则-首先，请考虑在哪里有遗漏的设计模式将其排除在外。如果不是，我将其编写为使最清楚地理解if中的条件。即，避免双重负片等。

对于这种情况，没有经验法则。但是，也许我们可以接着在if块中编写肯定的或最有可能的代码，而在else块或默认情况下忽略掉。