null 是有害的

翻译自：

http://peat.org/2013/12/07/null-considered-harmful/

 

我在最近几年花费了大量时间抱怨 null 的问题，我认为我现在需要认真表达自己的观点，否则我看起来就像个神经病。

 

在几乎所有我参与的项目里，我遇到的多数的错误都是由 null 引用引起的。许多在编译或测试阶段被发现，但总有漏网之鱼，很少有项目可以幸免。它们出现在各种地方：Web应用，桌面应用，嵌入式软件，游戏主机，移动设备——几乎只要有软件的地方，就有 null 异常。

 

什么导致了这些 bug ？

 

多数情况，是因为程序员没有在使用一个变量之前，先检查一个它是否为 null，而 null 出现的频率比我们想象中的更多： 它们也许来自于数据库，来自想表达数据缺失的API调用，又或者是某种竞争条件，还可能是难以计数的程序员无法考虑到的其他场景。

 

与 null 引用作斗争是作为一名程序员的日常工作，因为 null 引用是多数编程语言的“有用特性”之一：它的存在有时会存在混淆，或者为了表达一个值不可用，又或者是在一个值域或者结构里为“空”值留下位置。

 

null 的问题是它是任意变量都可以被设的值，任意变量都有被意外地设为 null 引用的顾虑。的确有那么一些明显并琐碎的情况不值得我们去担心，但是对于现在这种意外 null 引用泛滥的情况，的确是一个问题。

 

让我们稍微离题去看看另一个问题：内存管理。

 

对于使用显式（手动）内存管理的语言的程序员，需要非常有纪律性，否则他们的代码将面临内存溢出，野指针或者其他相关的问题。

 

这变成了一个足够大的问题，以至于语言设计者决定程序员应该从内存管理机制中解放。虽然程序员仍然需要考虑内存的使用效率，但他们已经不用显示操作分配多少内存等细节。让程序员远离内存管理消除了相当的一部分负担。

 

那么，相似的观点在 null 异常方面应该是什么呢？

 

对于使用显式 null 赋值和检查的程序员，需要非常有纪律性，否则他们的代码将面对各种意外的 null 引用问题。

 

null 引用已经变成了足够大的问题，以至于程序员应该从 null 的赋值和检查中解放。虽然程序员仍然会纠结于有歧义的数据和值域的占位符，但是他们已经不用显式赋值和检查 null 值。让程序员远离内存管理同样消除了相当的一部分负担。

 

（上面两段）听起来很相似？

 

从另一个角度而言，支持 null 引用的语言将更容易引起错误，并让技术缺陷不断累积——正如支持显式内存管理的语言，会更容易引起错误，并让技术缺陷不断累积一样。

 

用 Dijkstra 的话来说，我坚信 null 引用会从所有的“高级”语言中消失。