一個由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。