※ 引述《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