整理自： http://www.yegor256.com/2014/05/13/why-null-is-bad.html
在日常编码中，有个经典的 Java 空指针（NULL）调用如下：
public Employee getByName(String name) {
int id = database.find(name);
if (id == 0) {
return null;
}
return new Employee(id);
}那么这段方法有什么问题？这个方法的最大问题就是有可能会返回 NULL 对象。空指针（NULL）问题在面向对象编程角度上说是个很严重的问题，所有面对对象编程的过程中都会碰到类似的问题。甚至 Tony Hoare 向全世界道歉，忏悔他曾经发明了「空指针」这个玩意。
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement.原来，在程序语言中加入空指针设计，其实并非是经过深思熟虑的结果，而仅仅是因为它很容易实现而已。这个设计是如此的影响深远，以至于后来的编程语言都不假思索的继承了这一设计，这个范围几乎包括了目前业界所有的流行的编程语言。
对许多程序员来说，早就已经习惯了空指针的存在，就像日常生活中的空气和水一样。那么，空指针究竟有什么问题？
额外的错处处理
当然，有经验的编码人员自然会时刻意识到空指针问题的存在，那么有可能在编码的过程中加入额外的判断，就会规避这个问题，例如下面的写法：
// this is a terrible design, don't reuse
Employee employee = dept.getByName("Jeffrey");
if (employee == null) {
System.out.println("can't find an employee");
System.exit(-1);
} else {
employee.transferTo(dept2);
}那么这样的话就会多了额外的流程去处理因为空指针判断而多加的判断。例如，上面的处理逻辑和流程中，如果按照面向对象的思维书写，不考虑空指针的情况，只是简单的：
dept.getByName("Jeffrey").transferTo(dept2);就可以。加入空指针判断以后，程序往往会有额外以及复杂的逻辑判断。
语义不清晰
上面的问题自然可以规避，例如在 getByName() 这个方法中加入异常的判断，那么重新命名这个方法的名字为 getByNameOrNullIfNotFound() 。这样子从代码可读性的角度上说，从方法名字就可以判断这个方法会返回什么，
但是自然而然为了表意清晰就会让方法的名字变得越来越长（感觉有点在黑 Objective-C）。
为了表明这个歧义，除了正常的返回值以外，其他的空指（NULL Object）针情况都会返回一个异常。那么这里又会引申出另外一个问题，就是性能。从上面的代码考虑，如果返回了 NULL 以后再抛出一个异常，实际上这段代码是已经被执行了的，然后再加的判断。
例如，在示例中 getByName() 通常是个 Map 然后执行了 get 方法去搜索是否存在这个名字，如果不存在再抛异常，这样就会造成额外的执行时间：
Employee employee = employees.get("Jeffrey");
if (employee == null) {
throw new EmployeeNotFoundException();
}
return employee;当然，这个问题也是很好规避，例如只需要先搜索它的索引即可，然后再取值返回：
if (!employees.containsKey("Jeffrey")) { // first search
throw new EmployeeNotFoundException();
}
return employees.get("Jeffrey"); // second search那么，这部分操作判断只是针对空指针就多了一次搜索操作。我们考虑再优化下，直接使用迭代器处理：
Iterator found = Map.search("Jeffrey");
if (!found.hasNext()) {
throw new EmployeeNotFoundException();
}
return found.next();这样子似乎很好的解决了问题。
但是，我们编写这段代码的业务初衷似乎越来越远，然后方法的名字也变得越来越长，自然而然代码也变得越来越复杂。
如何最大程度得避免空指针？
本篇开头的这个问题一样，空指针的问题可以追溯到计算法发展史时期，同时空指针异常的情况也很多，甚至在程序运行阶段也无法避免空指针的情况。那么，在编码层面，我们需要注意哪些呢？
确认调用的的每个变量都已经被初始化
这点说起来很简单，但事实上随着业务的发展项目代码也会越来越庞大。这时候方法之间调用的关系也会越来越复杂，很难避免使用到的方法都已经明确被初始化。
所以这块单独放在这里，需要我们在编码的实话重点考虑变量存在的可能性，这其实大体上基于自己的实际编码经验。
尽量使用明确的值调用
如果已经明确某个变量（常量）的值，那么是可以安全调用它的方法的。例如对比下面的几行代码：
String a = null;
a.equal("b"); // 会产生空指针异常
"b".equal(a); // 推荐的写法很明显使用常量去做调用这代码会更健壮一些。
尽量避免在函数中返回 NULL
当如果在编写方法中考虑返回 NULL，这个时候则需要冷静下是否真的需要这样子做。因为，通常来说会有比返回 NULL 更好的处理方式。
自动装箱需谨慎
自动装箱确实为编写程序带来很多方便，但我们在编程时候也不能滥用自动装箱。
比如，下面这个程序依然存在空指针异常隐患：
Person jack = new Person("jack");
int weight = jack.getWeight();这种异常在我们使用一些 ORM 框架中会碰到，如果数据库对应的对象并不存在该值，而我们又在类中使用了一个基本类型与之对应，依然就会抛出空指针异常。在这种情况下就尽量使用包装类来对应，并且在使用该值时候先判断是否为空。
遍历谨防集合为空
for (int num : list) {
// for each num in list
}及时验证外部数据
在代码运行的过程中，尤其在解析外部数据的时候可能会引发影响不到的问题。例如下面的 Json 数据
{"name": null, age: 28}如果不处理完善，虽然这可能是外部原因造成，但直接使用 name 属性也会导致空指针的问题。
使用第三方库加强验证
很多第三方的 Common 库都会有验证空指针的方法，例如 Guava 中针对空指针的判断有个单独的包去处理。
Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5或者过滤 NULL 也会更加的方便
Joiner joiner = Joiner.on("; ").skipNulls();
return joiner.join("Harry", null, "Ron", "Hermione");使用 @NotNull 或 @Nullable 注解
强烈建议多使用注解来增加代码的可读性，例如多增加 @NotNull 或 @Nullable 注解，也可以加强代码静态检查方面可能会造成空指针的可能性，具体可以参见这里。
使用 Java8 的 Optional
很多「现代」语言都会有针对变量为空的可选链式判断，例如
Groovy 语言有一个 ?. 的操作符，可以安全地处理潜在可能的空引用（据说 Java7 曾被建议引入这个但是并没有发布）。它是这么用的：
String version = computer?.getSoundcard()?.getUSB()?.getVersion();虽然 Java 看起来非常的保守，但好在 Java8 中增加了 Option[T] 这个对象包来代表类型 T 的某一个值存在或者没有。那么上面的代码可以写成：
String name = computer.flatMap(Computer::getSoundcard)
.flatMap(Soundcard::getUSB)
.map(USB::getVersion)
.orElse("UNKNOWN");看起来似乎有点麻烦，但相信我你会爱上这样的写法，具体可以参见这里。
好了，针对空指针的总结和整理先到这里，如果你有更好的意见和建议，欢迎不吝提出。
参考资源
- https://github.com/google/guava/wiki/UsingAndAvoidingNullExplained
- https://stackoverflow.com/questions/271526/avoiding-null-statements
- https://www.jianshu.com/p/e216330e0a89
- http://www.deadcoderising.com/java-8-no-more-loops/
- http://www.yegor256.com/2014/05/13/why-null-is-bad.html
-- eof --
