今天小编分享的科技经验：再写if-else，就把你消灭，欢迎阅读。
翻开市面大部分编程教程，最早能够接触到的条件语句基本都是 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 比啥都清晰。
所以最好的做法是写一篇详细文档，从最原始的数学模型开始，表明采取何种计算策略，策略如何推倒，然后给整个方法加上注释附上文档地址，并且在每个分支的地方加上注释指明对应到文档中哪个公式。
总结起来，就是一句话：没有对与错，而是要看场景，任何时候，只要能让代码更易读和维护，就成功了。
