前言

我不喜欢业务代码中航天飞机式if/else语句, 它复杂而臃肿, 至少从美感而言, switch就比if/else优雅众多. 假如跨语言 比较的话, 私 认为ReasonML的模式匹配比起平常的switch语句又要强上太多. JS中对复杂推断的不同写法, 带来的觉得是很不同的, 这篇文章里, 我将 容易介绍几种用于 代替if/else的写法. 惟独 相熟更多代码思路, 能力 宽阔我们的思维, 假如不能学习写代码的更多可能性, 兴许我们就成了被代码操纵住的人.

if/else

我们以一个售后流程为例. 消费者购买商品后, 可能会由于错件漏件/ 品质问题/ 形容不符等缘由 联络商家进行售后服务, 其中可能会 波及退款/退货/换货/补发等售后 支撑服务, 商家对此次售后的服务状况也会影响消费者对商家的 爱好. 在这样的场景下, 我们 假如以下伪代码:

在这个场景下, 每一种售后缘由导向的售后 支撑服务内容是不同的, 比方错件漏件时消费者不能 取舍换货服务. 如此一来, 我们的推断条件也就成了一个[售后缘由 * 售后 支撑服务]的二维列表. 此时再外加依据售后缘由以及售后 支撑服务的不同, 推断条件妥妥地升为三维: [售后缘由 * 售后 支撑服务 * 消费者 爱好]

显然, 在这种重业务逻辑的地方if/else语句显得力不从心, 重要缘由如下:

1. 推断条件后置. 也便是说, 在} else if (serviceReason === ' 品质问题') {一句中, 我们通常要在行末 能力找到推断条件, 而些内容并没有高亮 支撑, 所以 时常与下一行的一般代码混在一同, 让人 目迷五色 无奈辨识.
2. 代码缩进不清楚, 当推断层数添加, 或是花括号中的内容加长, 那么阅读代码的时候, 寻觅if语句对应的 结束位置总是给人带来 累赘.
3. 奢靡的换行, 当if/else语句中的逻辑很短, 像else { user.love(-5 }这段代码, 占用了3行的位置显得过于奢靡.

三目运算符/短路 抒发式

在一些 容易的 抒发式中, 能够 使用三目运算符或短路 抒发式去简化推断, 如user.love这个函数的调用就 能够抽成 独自的一句, 所以下面这种推断 彻底 能够进行简化:

逗号运算符

通过括号和逗号运算符, 我们 能够把语句变成 抒发式去执行. 灵便 使用逗号运算符 能够使三目或短路 支撑一些更复杂的状况:

10秒筛选无用APP 安卓软件卸载技巧	大型垂直网站的2014年SEO的分析
摄影新手常犯的5个错误及如何避免	搞懂用光再拍照 不同光效下的人像摄影

不过上述代码, 在Standard 标准中是不被推举的. ESLint会 忠告你要求将这行内容转化为if/else写法. 固然, 你也 能够 批改ESLint 标准以关闭 忠告, 前提是你(及团队成员)喜欢这种写法, 也千万不要为了简化而简化.

switch/case

解决复杂的多分支推断时, 大 部分人会 取舍 使用switch作为长if/else的 代替品, 你觉得下面这种写法如何呢?

很遗憾, 看来switch语句并没有比if/else要好多少. 只不过有丝毫我要强调, 在上面这个例子中, 全部有关推断的 要害字的地方(如switch, case, &&, 这些都属于代码高亮区域), 几乎都存在与每一行开头的前两个语元内. 所以当前为止, 单纯就 搜索推断条件的难度而言, switch是要比if/else好上一些, 只管这种 好处会随着推断分支的添加而逐步被消磨(这算是一种遗憾吧).

其实还有一个令我觉得遗憾的地方, switch语句不能和短路运算符一并 使用, 下面是一种 舛误的示范:

略微有些难受, 毕竟 使用if推断会添加缩进. 现在让我们来看一种更加简洁的思路.

配置数据与业务逻辑 拆散

配置数据与业务逻辑 拆散(下简称配置逻辑 拆散)没有先决条件, 和三目短路 抒发式一样, 你随时都 能够开始在代码中 使用它. 使用配置逻辑 拆散, 通常需求定义一个用来 存放数据配置的对象, 同时要定义一个flag作为配置的键, 配置的值则 能够是函数, 数组等任意类型的值. 在执行逻辑的地方, 只有求将推断条件与flag进行比对, 就 能够猎取到当前推断条件下的业务逻辑 步骤:

有没有眼前一亮的觉得呢?

在上面的代码片段中, 我们将每一种状态的数据配置和执行业务逻辑的代码进行了 定然层度的 拆散, 使得代码长度短了不少. 通过逗号运算符, 我们 能够同时执行业务逻辑函数, 并且返回消费者对店家的映像分数.

假如你不想这么激进, 兴许下面的代码是一种好的 实际:

更加灵便的数据配置

上一节 使用了对象进行数据配置, 假如说有那么丝毫遗憾的地方, 那便是 只管属性的值可 认为任意类型, 然而属性 本身却不得不是字符串类型, 这使得某些场景下我们不能很好的 施展配置逻辑 拆散的作用. 设想以下场景: 每个月末, 商家会 选择出狂热粉丝(喜欢程度大于等于100)发送留言" 感激你"并赠送10元优惠券, 一般粉丝(分数0-100)发送留言" 感激", 黑粉(分数小于0)发送" 抱歉"并赠送10元优惠券.

等等, 喜欢程度分数是不定的!

显然我们不能用对象去 解决这样的数据( 只有我还没疯掉), 如下:

令人头大, 难到我们要用回if/else? 坏 信息是: 兴许是的.

不过, 我必须强调, 假使推断条件足够复杂—— 比方商家不只赠送优惠券, 商家还依据粉丝分数 高下不同, 送出QQ红钻/绿钻/黄钻/...一堆需求推断的礼品—— 使用if/else依然见面临我们在第一小节提到的代码 混乱等问题.

所以好 信息是, 使用配置逻辑 拆散 能够 解决更复杂的更 混乱的场景(并且你也 该当这么 使用). 你还记得我们方才提到的"属性 本身却不得不是字符串"这种略微的遗憾吗? 现在我们将要要解决这个问题! 请看以下代码:

使用Map进行数据配置是十分棒的一种写法, 然而假如你必须兼容IE阅读器的话, 你必须考量 使用其它的数据 构造用于 代替Map:

我们在上述两小节中提到的几种不同的代码 格调, 都遵照着将'配置' 施展到率先推断一步的理念. 在实际业务中, 你也 能够试试尝试混合配置逻辑 拆散以及 通例推断条件式写法, 其中重要考量的点应该是是配置率先推断, 还是推断率先配置.

后语

本文重要介绍了几种用于 代替 广泛场景中if/else的写法, 如三目+逗号运算符, 使用对象/Map/双数组进行配置数据与业务逻辑 拆散, 固然 解决业务逻辑的思路是一样的, 然而每种 步骤写起来的实际觉得却不一样, 孰优孰劣, 还请各位看官 细心 咀嚼一番.

喜欢的话 请小 搭档们 着手关注一下哦 谢谢 支撑 。