翻开市面大部分编程教程,最早能够接触到的条件语句基本都是if-else。


作为高级编程语言都有的必备功能,if-else在嵌入式编程过程中几乎是必用。但任何东西都有限度,滥用它,只会让代码逐渐抽象、离谱,最后成为“屎山”。


接手项目的程序员叫苦不迭;忍无可忍的CTO对着满屏的if-else终于下定决心,下次逮着谁再写if-else,罚款1000块。


那么,为什么if-else这么不受待见,怎么干掉它,不滥用它?


if-else的两宗罪


实际上,我们并不是杜绝if-else,而是建议少用。


究其原因,一共有两点:一是影响程序的运行效率;二是影响代码的可读性,增大运维难度。


目前,大部分人的观点是if-else的分支预测(Branch Prediction)会降低执行效率。


CPU执行一条指令分为IF、ID、EX、WB四个阶段。分阶段执行(也就是pipeline流水线执行)会先给出一个预测结果,让流水线直接执行,执行对了则继续;执行错了,则退回去重新执行,直到对为止。



比如说,在这样的代码中:


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 层,一个函数几百行,多层判断让人无从下手,绝望、愤怒、无奈喷涌而出,而且这样的惨案已经不止发生过一次。总结成一句话就是,看死人。



这种代码风格早在几十年前就被国外所批判,并被称之为“箭头代码”(Arrow-code)



实际工作中,我们能见到一个方法包含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比啥都清晰。


所以最好的做法是写一篇详细文档,从最原始的数学模型开始,表明采取何种计算策略,策略如何推倒,然后给整个方法加上注释附上文档地址,并且在每个分支的地方加上注释指明对应到文档中哪个公式。


总结起来,就是一句话:没有对与错,而是要看场景,任何时候,只要能让代码更易读和维护,就成功了。


参考文献

[1] 非典型技术宅:为什么建议少用if语句,不是运行效率!.2021.5.4.https://mp.weixin.qq.com/s/CHASap6dHJP_Cn2nL6aMiA

[2] CSDN:现在开始,把代码里的 ‘else’ 丢掉!”.2023.10.04.https://mp.weixin.qq.com/s/rRlV_sresmxGDFt8RMFraQ

[3] 知乎:优化代码中大量的 if/else ,你有什么方案?

[4] 前端有道:代码中大量的if/else,你有什么优化方案?.2021.5.21.https://mp.weixin.qq.com/s/LY-6IwOqXiBiN_TY0aq_6Q

[5] 阿里云开发者:如何优化你的if-else?来试试“责任树模式”.2021.1.26.https://mp.weixin.qq.com/s/Wib0Ly45te00HMUnIG-tbg


本文来自微信公众号:电子工程世界(ID:EEworldbbs),作者:付斌