该不该扼杀过多的if-else

4,816 阅读7分钟

面对过多的if-else,代码可能看起来比较冗余,搞不好又是一张被人到处转发的“我们项目几百几千行if”的图。但是经过各种设计模式和封装,if大大减少,但可读性可能稍微降低了,而且比较抽象。那我们应该如何取舍呢

抛开其他因素,如果if-else过多,可读性也许会好也可能会降低,可维护性也是或高或低;如果if-else少,代码高度抽象,可读性会低或者不变,可维护性可能会高也可能会低。这里大概可能会有几种情况

if平铺条件单一

这种情况,if精简不精简,可读性是不会变的,但是精简程度和可维护性是正相关的。至于为什么,看一下代码就可以感受到了

执行语句单一

if (a === 1) {
    console.log('this is 1')
} else if  (a === 2) {
    console.log('this is 2')
} else if  (a === 3) {
    console.log('this is 3')
} 
// ...还有很多
else {
    console.log('this is other')
}

精简代码:

// 如果上面的if a是从1到10
console.log(`this is ${a > 0 && a < 10 ? a : 'other'}`)
// 如果上面的if a是从1到5和从7-10
if ((a > 0 && a < 5) || (a > 7 && a < 10) {
    console.log(`this is ${a}`)
} else {
    console.log('this is other')
}
// a取值灵活区间
const area = [[1,2], [5,7], [10, 11]]
console.log(`${area.find(([from, to]) => {
    return from <= a && a <= to
}) ? a : 'other'}`)

这种情况,有没有精简,可读性都没有发生变化,如果是未精简的,写一堆if,你还是很容易看得出干啥。而可维护性就不一样了,要加一个或者多个数字,那么就要深入到某个if分支,一个个动手改,维护性低。但是,如果精简了的话,维护性大大增加,代码也简短。只需要寻找if的规律并封装所有的case即可,最后做到“条件驱动”

一些极简情况

有一些非常简单的情况,可以使用&&||、三元解决

// before
if (cb) {
    cb()
}
//after
cb && cb()

// before
if (!obj) {
    obj = {}
}
obj.a = 1
//after
(obj || (obj = {})).a = 1

// before
if (type === true) {
  value = 1
} else {
  value = 2
}
//after
value = type ? 1 : 2

// before
if (type === DEL) {
  this.delateData(id)
} else {
  this.addData(id)
}
// after
this[type === DEL ? 'delateData' : 'addData'](id)
// or
;(type === DEL ? this.delateData : this.addData)(id)

// before
if (a === 1 || a === 2 || a === 10) {
    console.log('ok')
}
// after
if ([1, 2, 10].includes(a)) {
    console.log('ok')
}

条件单一、执行语句单一的情况,建议优化指数:★★★★★

执行语句复杂

if (a === 1) {
    console.log('this is 1')
} else if  (a === 2) {
    console.log('this is 二')
} else if  (a === 3) {
    console.log('this is three')
} 
// ...还有很多
else {
    console.log('this is other')
}

精简代码:

const map = {
    1: 'this is 1',
    2: 'this is 二',
    3: 'this is three',
    // ...很多
}
console.log(map[a] || 'this is other')

这种情况,和执行语句单一类似,也是可读性不变,代码减少了可维护性只是略好一点。通常的解决办法就是k-v映射了。加一个条件,就在map中加多一对k-v(由于条件处理复杂,所以条件上没有优化空间了,必须写出来)

这种场景,平时应该会比较常见转为switch。如果执行语句很复杂无规律,写k-v的缺陷就来了:一个key被迫对应一个callback函数,还会花时间斟酌传值问题,而且代码量也没发生变化,此时不建议优化

if (a === 1) {
    console.log('this is 1')
    alert(a * 100);
} else if  (a === 2) {
    console.log('this is 二')
    document.body.innerHTML = a + 1 + b
}
// after
const map = {
    1: (a) => {
        console.log('this is 1')
        alert(a * 100);
    },
    2: (a, b) => {
        console.log('this is 二')
        document.body.innerHTML = a + 1 + b
    }
}
map[a](a, b) // 代码量并没有减少也没有增强维护性

问题来了,条件单一,但处理语句有简单的也有复杂的怎么办?case by case,先归类再分情况,最终只会剩下少量if和switch的

小结: 条件单一、执行语句复杂的情况,有规律时建议优化指数:★★★,无规律时,建议指数:★

if平铺条件复杂

如果条件复杂,执行语句单一,那么条件可以通过&&||、三元来简化,或者是平铺if-return,问题也迎刃而解。然而,条件复杂,执行语句大概率也是复杂的。

if (a === 1) {
  console.log(1);
} else if (arr.length === 3) {
  alert('this is length 3 arr');
} else if (a === 2 && b === 1) {
  console.log(2);
  console.info('haha');
} else if (a === 2) {
  console.log(222);
  document.title = 'a = 2';
} else if (arr.length) {
  console.error('arr is not empty');
}

都没有规律可循,那么就真的没有进一步方案了。但是我们观察一下,发现一些条件是有交集的,如a === x,我们可以把这种类型的if抽出来:

const handleA = {
    1: () => {
        console.log(1);
    },
    2: () => {
        if (b === 1) {
            console.log(2);
            console.info('haha');
        } else {
            console.log(222);
            document.title = 'a = 2';
        }
    }
}
const handleArrLen = {
    3: () => {
        alert('this is length 3 arr');
    }
}
if (handleA[a]) {
    handleA[a]()
} else if (arr.length) {
    ;(handleArrLen[arr.length] || () => {
        console.log(222);
        document.title = 'a = 2';
    })()
}

这样子,可以把逻辑模块化,增加可读性和可维护性,但是牺牲了精简性。

注意,上面这样子条件模块化了,意味着同一类的条件都会归到一起。如果业务逻辑对if条件有严格要求的,比如一定要先判断a === 1,再看看arr.length === 3,再看a === 2 && b === 1,按照这样的顺序,那就不能这样做了

还有一种情况,就是if里面直接调用已经封装好的函数,没有其他语句(其实就相当于退化为条件复杂,执行语句简单了):

if (a === 1) {
  f1()
} else if (arr.length === 3) {
  f2()
} else if (a === 2 && b === 1) {
  f3()
} else if (a === 2) {
  f4()
} else if (arr.length) {
  f5()
}

这种情况(前提条件,不会经常改这里,如果是经常改,还是会吐血的),减少if后也不赖:

const index = [a === 1, arr.length === 3, a === 2 && b === 1, a === 2, arr.length].findIndex(Boolean)
if (index !== -1) {
  [f1, f2, f3, f4, f5][index]()
}

如果所有的else if都是互斥的,没有交集,那么换成if-return更好

if (a) {
    // do xx about a
    return
}
if (b) {
    // do xx about b
    return
}

小结:如果条件复杂,执行语句单一,建议优化指数: ★★★★★;如果执行语句也复杂,当条件可以模块化的且没有顺序要求,建议优化指数: ★★★★。当条件有严格顺序要求、无规律可循,不建议强行减少if-else

if条件有嵌套

嵌套实际上就是平铺的增强,平铺嵌套平铺,我们可以当作是多个if平铺条件复杂的情况来看。例如有如下代码,我们寻找一些规律来优化一下

  if (id === 1) {
    console.log(1);
    if (type === 2) {
      console.log('type2');
    } else {
      console.log('type3');
    }
  } else if (id === 2) {
    console.log(2);
    if (type === 3) {
      console.log('id2 type3');
      if (ext === 1) {
        console.log('ext1');
      }
    }
  } else {
    console.log('other id');
  }

根据id划分:牺牲了其他因素的可读性,但对于id的维护性增强了

const handleId = {
    1: () => {
        console.log(1)
        console.log(type === 2 ? 'type2' : 'type3')
    },
    2: () => {
        console.log(2)
        // 这里建议优化指数为★★,可能可读性低,所以保持现状也行
        // eslint一开,这套凉凉,必须写回普通if-else
        type === 3 && (console.log('id2 type3'), ext === 1) && console.log('ext1')
    }
}
handleId[type] ? handleId[type]() : console.log('other id')

如果此时根据type划分,那么难度大大增加了,这就是人人惧怕的重构了。如果后面业务逻辑,的确是以type为主导的,那重构也是早晚的事情了。所以,前期的设计以及产品逻辑,将会决定后面的维护舒服不舒服了

小结: if条件有嵌套情况,拆分if,其实就是平铺的if嵌套平铺的if,如果有规律可循,那么按照前面的平铺来减少if。如果没有规律、也不是逻辑侧重的点,那么就不建议减少if了

总结

  • 条件简单,执行语句单一,强烈建议减少if-else来优化,用条件驱动结果(&& ||三元或者是自己写小逻辑)
  • 条件简单,执行语句复杂,可保持现状或者换成switch,如果不复杂可以使用map映射
  • 条件复杂,执行语句单一,强烈建议减少if-else来优化;如果执行语句也复杂,当条件可以模块化的且没有顺序要求,比较建议优化。当条件有严格顺序要求、无规律可循,不建议任何改动
  • 嵌套if,拆分为平铺if来判断如何优化或者不改动

关注公众号《不一样的前端》,以不一样的视角学习前端,快速成长,一起把玩最新的技术、探索各种黑科技