代码掌控力

从list.isEmpty与list.size()==0引发的争论

公司里有4个员工,分别为CTO技术负责人老C,架构师小贾,高级开发工程师小高,开发工程师小开.
有一天,针对一段代码,小贾,小高,小开起了争执:

  List<Method> methods = interfaze.getMethods();
  if (changeMethods.size() == 0){
      ...
  }

小高:  一看就是新人的代码，好low.判断集合是否为空集合，用isEmpty.
小贾:  有个工具类:

  public static boolean isEmpty(Collection coll) {
      return (coll == null || coll.isEmpty());
  }

小高: 一般来说判断一个集合是否为empty,要先判断集合是否为空,而后是否为empty,工具类只调用一次,书写简单.
小贾:  嗯,同时风险也降低了,不会手抖时候把==0写成==1.
小开一脸茫然:  这代码不是我写的啊.
老C这时也过来了:  嗯,我们先看看这个代码在哪里被调用吧,我们看到,interfaze.getMethods()肯定不会返回null 嗯,我们再看看集合类的isEmpty():

 public boolean isEmpty() {
       return size == 0;
 }

小开: 咦,他也是size == 0的判断呀.
小高:  优秀的代码就是短小精悍,通俗易懂,直接==0也太low了.
小贾:  告诫你们一下,在使用方法传递的参数时,一定要判断是否为null,因为你不知道这个方法会不会会被其他人改写,是不是会有null.
小开:  这个代码是核心代码,怎么会被别人随便改呢,就算改,也要有一定的规则啊,原来返回个空对象,现在非要返回null,含义也不一样,说不通啊.
老C:  其实从形式上看,两者并没有什么不同,代码是给人看的,能看懂,能跑,那基本要求就达到了.
         从效率上看,直接使用size==0,少一个判断,那么累加起来,对于执行效率的提升也是有一定帮助的,但是,如果后期有人变更了方法参数,使其为null,那么代码就防护不了了.如果要这样用,那么就一定要强制遵循规范,返回对象可以是空对象,但绝不能是null.
          所以从代码防护角度考虑,我们可以用工具类的isEmpty(),但是呢,知道他的具体实现后,是不是就一定要用他呢.也不一定,如果你有绝对的掌控力,那就没问题.不管怎么用.,没有low不low的,合适的就是好的.
  这个,也反应了一个代码掌控力,知道怎么用,在哪里用,更知道为什么这样用!

boss: 看你们今天活力四射啊,今天聚餐,走起!哦,对了,站起来,要慢一点,别急.