一个由isUndefined引起的争议

handlerOper(operInfo, node) {
  const graphInst = this.graphInst
  this.operateNodes = isUndefined(node) ? graphInst.getSelectedNodes() : [node]
      ......
}

由上面的代码，今天我的同事问了我一个问题，“这里你非得用lodash的isUndefined的吗？”为什么不把

isUndefined(node)

换成

node ?  [node] : graphInst.getSelectedNodes() 

或者

!node ?  graphInst.getSelectedNodes()  :  [node] 

我答，“我想更确定的表达什么情况下会执行为‘true’的情况，什么情况会执行‘false’的情况”。
他问，“你不就是要表达node存在与不存在时的逻辑吗？我那种也行啊”
我答，“不存在就是用undefined来表达吗，我这样不很清楚吗”

后来同事非常不情愿的结束了对话，当然我也没有让他认可。

能有这个认识是在之前的创业公司的前辈告诉我，避免使用隐式类型转换，尽量不要用，等于与不等的判断也要尽量用!==和 ===，当时的我并没有因为隐式转换而踩过什么坑，但是他们是有过的，但我认可这一点的原因主要是来源于这样带来的可读性。

边写边来分析一下同事的question，他的为什么会知道我要表达的是存在与不存在？而不是“为空字符串与不为空字符串”，“为零不为零”，“为空数组不为空数组”，“为空对象不为空对象”？
他能这么认定，你们也许会说是对业务上下文理解。是的，但如果是对于维护代码的新同事那是不是会有以上的疑问呢，按照他觉得的写法。

同事还说，如果node是null或者其他不符合要求的node走到后面的逻辑，后面的处理就会报错了。当时我并没有回答他这个问题，现在想来，不符合的node格式在这里不是我需要cover的，而是使用node的地方需要cover的，我这里只是判断是否有node传入。

有时代码可读性就像润物的春雨一样无声，只有你读过好的代码，你才能知道什么是坏代码的味道。有人说读不懂代码也许不是别人写得不好，而是你能力不够，但是我认为，能够让别人花10秒钟读懂的代码为什么要让别人花10分钟去理解上下文。

Whatever，每个人都有每个人写代码的风格，然而喜欢和谁一起写代码就体现大家的favor。