Code Review 是一场苦涩但有意思的修行。
近期对团队负责的项目，进行了一次 Code Review，代码评审过程中遇到的那些编码坏习惯，笑的合不拢嘴。不过，评审中很多代码编写问题，以往都多次提及过，所以还是按奈不住心中怒气的小火苗。
作为用代码编写人生的程序员，能拥有写一手健壮代码的本领，那绝对很有必要。因为健壮的代码能够把 Bug 扼杀在摇篮里，能够让问题止步于上线前。
那么，怎样才能练就写出健壮代码的本领呢？
本次着重谈谈那些代码编写时的一些坏习惯，改掉这些坏习惯，相信会向健壮代码迈进一大步。
一、编码时易忽略性能的坏习惯
坏习惯一：调用低效的构造器，创建包装类型的对象。
反例：
正解：
解惑：使用 Long.valueOf(long) 代替 new Long(long)，可以提高性能。
如 Long 源码所示，如果当传入的值介于 -128～127 时，会优先从缓存中返回缓存的值，而不是进行 new，充分利用空间换取时间，所以当值介于 -128～127 时，采取 Long.valueOf(long) 的效率要比 new Long(long) 快很多。
建议：
- 凡是涉及到 Long, Integer, Short, Character 以及 Byte 创建对象时，优先采用高效的 valueOf() 方法，而不是直接用低效构造器创建实例。
- 享元设计模式在这儿用到了，什么是享元模式？（留个作业）
坏习惯二：使用 keySet 迭代器迭代 Map，获取对应的 value。
反例：
正解：
解惑：keySet 方式遍历 Map 的性能不如 entrySet 性能好。
如果采用 keySet 的方式获取 Map 中 key，然后通过 key 获取 Map 对应的 value，如上图 HashMap 源码所示，每次都需要通过 key 去计算对应的 hash 值，然后再通过 hash 值获取对应的 value，效率会低不少。
建议：
- 如果想获取 Map 对应的 key 和 value，则推荐使用 entrySet。
- 如果只是单纯获取 Map 对应的 key，则推荐使用 keySet。
坏习惯三：使用 new Date().getTime() 获取当前时间戳。
反例：
正解：
解惑：如下图 Date 源码所示，Date 构造方法中最终还是调用了 System.currentTimeMillis() 方法来获取时间戳。
建议：
- 获取当前毫秒数采用 System.currentTimeMillis()，而不是new Date().getTime();
- 获取更加精确的纳秒级时间值，采用 System.nanoTime；
- 在 JDK8 中，针对统计时间等场景，建议使用 Instant 类。
坏习惯四：循环中使用 ”+“ 号拼接字符串。
反例：
正解：推荐使用 StringBuilder/StringBuffer 进行字符串拼接。
解惑：「Java 程序该怎么优化？技巧篇」以前的这篇分享做过试验，本次不赘述。
二、编码时易犯的一些小毛病
毛病一：变量作为 equals() 方法的调用方。
反例：
正解：
解惑：totalCount 应该作为方法 equals() 的调用方，而不是参数 作为调用方，因为参数作为调用方会出现空指针异常。
建议：
- 字符串的比较，常量建议当做 equals() 方法的调用方；
- 字符串判断空，建议用项目中的工具类。
毛病二：对象为 null 的检查滞后。
反例：
正解：请在使用 data 对象前，做好是否为 null 的判断。
解惑：后置对象为空的检查，可能会导致空指针异常的发生。
毛病三：要求传入非空的方法，传入空值。
反例：
正解：signInfo 变量的值可能存在为空的情形，导致发生空指针异常。
建议：发生异常的时候，方法该终止就终止；尽量做好防御性编程，该校验的参数进行必要的校验。
三、寄语写最后
常在河边站哪有不湿鞋，再牛逼的码农，编码也会有失误的时候，很有必要借助一款代码检查工具，做最后一道防线。
在这里，推荐 FindBugs、Checkstyle、SonarQube 三款代码检查工具，不过我用的最多的当属 FindBugs，可以拿去一试，使用门槛几乎为零。
好了，编码中易犯的那些臭毛病，本次就谈到这里，不知道有多少条是触动了你的心弦，希望有则改之。
关注同名公众号：一猿小讲，回复「1024」可以获取精心为您准备的职场打怪进阶资料。
一起聊技术、谈业务、喷架构，少走弯路，不踩大坑，会持续输出原创精彩分享，敬请期待！