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