※ 引述《samtree (嗯....？)》之銘言： : ※ 引述《awert ( )》之銘言： : : 理論上是第二種，差別單純在於 : : a如果是null時，不會有NullPointerException : : 但我覺得微調這個沒有太大意義就是了.. : 對我而言 : 這兩種寫法已經不是哪種較好的問題了 : 第一種寫法根本就是錯誤的寫法 : （當然如果你百分之百確定該字串絕對不會是null) : 或是你真的需要丟 nullPointerException : (不過例外處理的成本比判斷是否為 null 高出許多） 用推文有點慢.. 我的想法是這樣子的，這個idiom並沒有問題。 但是，實際寫code時遇到要處理null問題時， 我不會鑽牛角尖考慮哪一種處理null的方式比較漂亮/有效率， 而是要先看為什麼要處理null。 有時候要判斷為null都是因為其他code不必要的動作 舉例來講 public String getString() { if (someCondition()) { return myString; } return null; // bad } public String getList() { if (hasMoreThanZero()) { return myList; } return null; // bad } 上面第一個method可以考慮使用空字串，第二個則是空list如Collections.emtpyList() 如果是物件，那麼是否能用null object ? 這些都是可能可以改進的地方， 當然，有時候這些東西不是單一一個programmer可以去決定的事， 也不會這麼巧都可以解決，所以我們得乖乖的處理null。 這時，就要考慮到第二點，怎麼處理比較有效率。關於這點， 我認為是不需要考慮，等到是因為這樣而造成效率低落時再說， 更何況其實上面的寫法也只是將判斷丟給String的equals裡面。 第三點是，是否該允許null出現 如果a不該為null，那麼這個idiom不就隱藏了一個可能潛在的問題 ? 最後一點則是比較我個人較龜毛的想法， SOME_CONSTANTS.equals(a)乍看之下很棒，不需要去處理 可是當實際他人在維護/更改code時，可能會造成一點困擾， 因為code裡並沒有清楚的提醒閱讀者，這個a可能是null。 -- We who cut mere stones must always be envisioning cathedrals. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.35.186.241