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]
我答，“我想更確定的表達什么情況下會執(zhí)行為‘true’的情況蜻懦，什么情況會執(zhí)行‘false’的情況”甜癞。
他問，“你不就是要表達node存在與不存在時的邏輯嗎宛乃？我那種也行啊”
我答悠咱，“不存在就是用undefined來表達嗎，我這樣不很清楚嗎”
后來同事非常不情愿的結束了對話征炼，當然我也沒有讓他認可析既。
能有這個認識是在之前的創(chuàng)業(yè)公司的前輩告訴我，避免使用隱式類型轉換谆奥，盡量不要用眼坏，等于與不等的判斷也要盡量用!==和 ===，當時的我并沒有因為隱式轉換而踩過什么坑雄右，但是他們是有過的空骚，但我認可這一點的原因主要是來源于這樣帶來的可讀性纺讲。
邊寫邊來分析一下同事的question擂仍，他的為什么會知道我要表達的是存在與不存在？而不是“為空字符串與不為空字符串”熬甚，“為零不為零”逢渔，“為空數組不為空數組”，“為空對象不為空對象”乡括？
他能這么認定肃廓，你們也許會說是對業(yè)務上下文理解。是的诲泌，但如果是對于維護代碼的新同事那是不是會有以上的疑問呢盲赊，按照他覺得的寫法。
同事還說敷扫，如果node是null或者其他不符合要求的node走到后面的邏輯哀蘑，后面的處理就會報錯了。當時我并沒有回答他這個問題葵第，現在想來绘迁，不符合的node格式在這里不是我需要cover的，而是使用node的地方需要cover的卒密，我這里只是判斷是否有node傳入缀台。
有時代碼可讀性就像潤物的春雨一樣無聲，只有你讀過好的代碼哮奇，你才能知道什么是壞代碼的味道膛腐。有人說讀不懂代碼也許不是別人寫得不好躬窜，而是你能力不夠，但是我認為针史，能夠讓別人花10秒鐘讀懂的代碼為什么要讓別人花10分鐘去理解上下文材鹦。
Whatever，每個人都有每個人寫代碼的風格律罢，然而喜歡和誰一起寫代碼就體現大家的favor膀值。
