宁愿犯编译期错误，也不犯运行期错误 ---再谈 char *p = “abc“；的不合理性以及写成 if(NULL == p)而不是if(p == NULL)的理由

本文主要是介绍宁愿犯编译期错误，也不犯运行期错误 ---再谈 char *p = “abc“；的不合理性以及写成 if(NULL == p)而不是if(p == NULL)的理由，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

年末，各方催进度，大家也在抓紧时间码代码，各种低概率死机问题频出，这些低概率的死机问题非常难以重现和定位，即便是修改好了，也需要验证，如果没有出现死机，那也不能完全保证修改好了。总之，低概率问题就是这么折腾人。

那低概率死机问题是怎么产生的呢？其实，很多时候都是程序猿编码不细心，对一些问题理解不透彻造成的。比如最常见的内存错误问题。

在本文中，我不去具体讨论某某问题，而是以一个简单的例子说明安全编程的重要性，我们来讨论编译期错误和运行期错误。我们先看一个有潜在问题的程序:

#include <iostream>
using namespace std;int main()
{char *p = "abc";// ...// ...char c = 100; // 随机值if(123 == c) {cout << "if" << endl;*p = '\0';}// ...return 0;
}

在99%的时候（准确概率是255/256），运行上面程序是不会有什么问题的，但是，如果当c的值是123, 那么上述程序运行的时候会崩溃。究其原因，是因为后面维护该代码的程序猿看到char *p = "abc";后(尤其是看到char *p后)，判断p所指向的值是可以改变的，于是就写了*p = '\0'; 上面程序产生了低概率的运行错误。那作为程序猿，我们应该怎样避免这样的问题呢？我们更改一下上面的程序：

#include <iostream>
using namespace std;int main()
{const char *p = "abc";// ...// ...char c = 100; // 随机值if(123 == c) {cout << "if" << endl;*p = '\0';}// ...return 0;
}

再编译一下，发现根本通过不了编译，此时，程序猿就意识到自己哪个地方有问题了，于是去修改 *p = '\0'; 这样的错误。这样，就不会有什么低概率的运行期错误了。所以说，加上const是安全的，它能保证程序错在编译期间，强迫程序猿做出修改。反之，如果到了运行期，软件到了用户手上，出现运行期错误，那就惨了。
有时候，一些程序猿遇到上面第二个程序的编译错误后，居然想办法把const去掉，让程序通过了编译，而且运行居然也没有出错，以为万事大吉，无语啊

再举个常见的例子，我们一直强调： if(NULL == p)比if(p == NULL)好，其实是在防止程序猿将 == 写成=, 我们可以看一下，如果程序猿不小心，将==写成了=, 那就是if(NULL = p)和if(p = NULL)了, 前者会产生编译期错误，编译器会发现，强迫程序猿修改；后者极有可能产生运行期错误，用户会发现。