再论if (null == p)风格

本文的copyleft归[e-mail]所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。
作者：[e-mail]
博客：linuxfocus.blog.chinaunix.net    

基本上稍微有些经验的程序员，都会知道条件判断中if (null == p)的这个风格。
但是随着编译器的发展，很多人还是觉得if (null == p)这种形式，不太利于阅读，而且当if (p = null)时编译器已经可以报出warning了。所以在日常开发中，很多人都放弃了if (null == p)这种风格。
对此我仍然持有不同 意见，仍然坚持if (null == p)的风格，来尽可能的消除不必要的笔误而带来的bug。

首先，将检查工作完全交给编译器，对此 我是不放心的。毕竟编译器也是软件产品，不免会有bug。且当if条件比较复杂时，编译器是否可以真正检查来了。谁能保证？
其次，当条件复杂时， 程序员很有可能会多加一个括号，而导致编译器检查不出。
最重要的就是，当条件判断中还有宏的时候，程序员就更容易多加上一个括号，从而导致编译器 的检查不出if (p = null)的这种情况。

下面举例说明
当程序员写宏定义的时候，安全的方法是为参数加上括号。
如
#define TEST1(x)      (flag == (x))
而当程序员使用宏的时候，为了防止该宏操作没有为参数加括号——这很有可能，出于安全 考虑，也会为参数加上括号。
这时，错误的将p == 1写成了 p=1
TEST1((p = 1))
那么编译器是无法检查出这个 错误的。

因此，我认为开发人员是不可能完全避免笔误的，那么在开发过程中，仅仅是一个简单的条件风格的应用，就可以避免一些bug。这无 疑是很值得的。尤其是，这种几乎没有任何代价。