本文讨论了if-else语句在编程中的滥用问题以及对代码可读性和运行效率的影响。针对这些问题，文章提出了几种优化if-else的方法，如使用三元运算符、switch语句和责任链模式等。同时，文章也指出了优化if-else并不是一种绝对准则，而是根据具体情况来选择合适的优化方式。
• 💡 if-else的滥用会导致代码逐渐抽象、增加运维难度，影响代码的可读性。
• 💡 优化if-else的方法包括使用三元运算符、switch语句和责任链模式等，可以简化代码结构。
• 💡 优化if-else并非一种绝对准则，应根据具体情况选择合适的优化方式。
翻开市面大部分编程教程，最早能够接触到的条件语句基本都是if-else。
作为高级编程语言都有的必备功能，if-else在嵌入式编程过程中几乎是必用。但任何东西都有限度，滥用它，只会让代码逐渐抽象、离谱，最后成为“屎山”。
接手项目的程序员叫苦不迭；忍无可忍的CTO对着满屏的if-else终于下定决心，下次逮着谁再写if-else，罚款1000块。
那么，为什么if-else这么不受待见，怎么干掉它，不滥用它？
if-else的两宗罪
实际上，我们并不是杜绝if-else，而是建议少用。
究其原因，一共有两点：
一是影响程序的运行效率；二是影响代码的可读性，增大运维难度。
目前，大部分人的观点是if-else的分支预测
会降低执行效率。
CPU执行一条指令分为IF、ID、EX、WB四个阶段。分阶段执行
会先给出一个预测结果，让流水线直接执行，执行对了则继续；执行错了，则退回去重新执行，直到对为止。
比如说，在这样的代码中：
int a = 0;
a += 1;
a += 2;
a += 3;
CPU并非运行完a=0后执行a +=1，而是在运行a=0读执行后，马上运行a +=1的读执行。
流水线执行的好处很多，但对if语句来说，就会开启分支预测，如果预测失败，就会影响执行时间。但未对数组排序前提下，分支预测大概率会失败，从而导致指令执行结束后重新读取下一条指令，无法发挥流水线效果。
说白了，只有分支预测一直成功，CPU执行效率才会大幅提升。
不过，需要强调的是，所有带有跳转结构的语句比如if、switch、for都会出现这种情况。而且，现代CPU性能远超过去，只有存在巨大量if-else情况才会影响性能，即便出现性能问题，也得在一个结构清晰的架构上分析性能是不是才能更好的定位，实在不行也可以把这段替换成汇编。
所以相比来说，导致程序运行效率下降并非if-else的最大原罪，而是影响可读性。
代码本质是给人看的，人得能看懂，从上到下扫一下大概就明白设计意图、思路就是好代码，这样的代码也是基本没有if-else的，如果还需要反复从上看到下，再从下看到上，这样的代码即使这次看懂隔一段时间也会忘记的。也就是“高内聚，低耦合”。
许多工程师在接手老项目时，时常会收到扑面而来的是，代码中可能会充斥着大量的 if/else ，嵌套 6、7 层，一个函数几百行，多层判断让人无从下手，绝望、愤怒、无奈喷涌而出，而且这样的惨案已经不止发生过一次。总结成一句话就是，看死人。
这种代码风格早在几十年前就被国外所批判，并被称之为“箭头代码”
。
实际工作中，我们能见到一个方法包含10个、20个甚至更多的逻辑分支的情况。而更为致命的情况就是if-else的多层嵌套。
代码的多层嵌套拥有很大隐患，也给代码库增加了很多不必要的复杂性。
人脑一次只能处理几件不同的事情，因此当面临需要深入分析多个代码层级时，很容易忘记上一层的关键逻辑，导致一些不必要的错误。
还是那句话，代码是给人看的，我们的业务流程已经足够复杂了，多层嵌套还会进一步增加了其复杂度。
遇到这种情况怎么办，不要慌，直接干掉if-else。
怎么干掉if-else
第一种方法：排非策略
优化前：
优化后：
第二种方法：三元运算符
三元运算符相比if-else来说，只需一行语句，代码简练精炼。
示例一：
示例二：
第三种方法：使用switch、key-value和Map
Switch显然更简单，而且，不同的条件分支之间没有嵌套，并且它们彼此独立，逻辑很清楚。不过，代码本身也会有点多。
此时key- value和Map就是很好的方法。
第四种方法：逻辑与运算符
有些时候我们可以使用逻辑与运算符来简化代码。
第五种方法：使用 includes 处理多重条件
第六种方法：责任链模式和策略模式
责任链模式是实现了类似“流水线”结构的逐级处理，通常是一条链式结构，将“抽象处理者”的不同实现串联起来。策略模式的目的是将算法的使用与定义解耦，能够实现根据规则路由到不同策略类进行处理。
当然，并不是说用if-else就很low，用设计模式就高大上，二者擅长场景不同，if-else足以满足大部分日常需求的开发，且简单、灵活、可靠，而设计模式则是为了更简洁、拓展性好、性能更优、可读性更好等。
抛弃else吧，你会打开新世界
当然，无论哪种重构方法，都只是优化。
归结起来，最简单的方法就是在写代码之处，抛弃else。抛弃else就可以减少嵌套层数，有效降低代码复杂度。让代码更简单，结构更清晰，更容易维护。
如果我们抛弃if-else块中的else并优先处理这块逻辑。先处理小的边界情况，如果必要的话提前返回；否则，将主流程保留在函数的最外层。
同样的思路也可以应用于处理多个边缘情况：
由于边界情况在函数的顶部得到了处理，开发者在后续添加新代码时不太可能忽略这些情况，从而降低了引入错误的风险。处理边缘情况并早期返回可以减少不必要的计算，从而可能提高代码的执行效率。
简化的代码结构更容易被同事理解，从而使代码审查过程更顺畅，减少潜在错误和不良事件传播。
当然，也有工程师认为，不要过度关注if-else的数量和层数，而是要关注语义是否清晰，单纯减少if-else但又让代码更难阅读反而是画蛇添足。乱优化if-else没什么好处，应该优化的是本身条件的分割，把流理清楚后if-else比啥都清晰。
所以最好的做法是写一篇详细文档，从最原始的数学模型开始，表明采取何种计算策略，策略如何推倒，然后给整个方法加上注释附上文档地址，并且在每个分支的地方加上注释指明对应到文档中哪个公式。
总结起来，就是一句话：
没有对与错，而是要看场景，任何时候，只要能让代码更易读和维护，就成功了。
本内容为作者独立观点，不代表虎嗅立场。未经允许不得转载，授权事宜请联系 hezuo@huxiu.com
如对本稿件有异议或投诉，请联系tougao@huxiu.com
