风格问题！条件与条件 == NULL答案

【问题标题】：Style question !condition agains condition == NULL风格问题！条件与条件 == NULL
【发布时间】：2010-11-28 20:46:54
【问题描述】：

如果您调用某个函数，并且该函数在发生错误时返回 NULL（例如 malloc() 或 fopen()），那么两者哪个更好：

FILE *fp = fopen(argv[0], "r");

if (fp == NULL) {
    // handle error
}

或

if (!fp) {
    // handle error
}

这只是风格问题吗？我认为第一个更清晰更明确，但我很少用 C 编码:-)。

【问题讨论】：

标签： c coding-style

【解决方案1】：

我更喜欢与 NULL 进行比较，因为它清楚地表明比较的两个操作数都应该是指针。这个

(!p)

或者这个

(p == 0)

要求您一眼就知道 p 的类型是什么（整数？布尔值？）。我认为所有编码都应该假设您将不得不在 9 个月后的凌晨 4 点（即凌晨 4 点，对于那些不眠不休的人）进行调试。在这种情况下，每一点都会有所帮助。

哦，在测试相等性时最好将常量作为第一个操作数，这样如果你不小心把它变成了一个赋值，编译器就会出错并中止。

【讨论】：

这是我从未得到的关于整个 LHS 上放置常量的事情：如果我能记得这样做，我难道不记得放两个 = 符号?
大多数编译器警告在条件中有赋值，所以这不是一个大问题，但有时仍然有用。
@Jason：第一个是自动遵循的做法，第二个要求您实际上要小心按两次 = 并且编辑器实际上会抓住按键。记住，凌晨 4 点！
@Kos：是的，除非您正在修改不关心减少编译器警告的人的第 3 方代码。在这种情况下，与您的修改相关的警告很容易被忽略。
我不喜欢颠倒的条件：我不是将 null 与某物进行比较；我正在测试某些东西是否为空。根据@dennycrane，它读错了 - 类似于尤达。另外，当你比较两个变量时它会崩溃......所以它是一个糟糕的拐杖。

【解决方案2】：

我相信这是风格问题。就个人而言，我更喜欢第二种选择。其他人喜欢第一个，因为它更清晰，更“正确”。有些人甚至写if (NULL == fp)，这样他们就永远不会不小心忘记一个=并将其变成一项作业。总而言之，我认为这是一个品味问题，而且保持一致可能更重要。

【讨论】：

我不喜欢尤达的条件。感觉就像在说“如果绿色是水，……”。此外，无论如何，我的编译器都让我在条件中进行分配。
在某些情况下，例如：if (SOME_CONST == long_function_name(lots, of, parameters, with, long, names)){ 通过将常量放在前面，您不必滚动查看与什么进行比较。（我讨厌对函数参数使用换行符，所以我更喜欢这种方法）。
我喜欢“尤达条件” - 最后是这个愚蠢的词:) 谢谢丹尼！

【解决方案3】：

在这种情况下，我更喜欢第一个，因为您正在显式比较该值以查看它是否为空（恰好为 0）。

第二个读起来好像fp 是一个布尔值，但它不是。

这就像说“这个指针无效吗？” vs "这个指针是假的吗？"

你哪个更易读，当然，这是一个见仁见智的问题。

【讨论】：

【解决方案4】：

我更喜欢 "==";我认为读者必须少想。这也是我讨厌 typedef 的原因。

【讨论】：

【解决方案5】：

只是风格问题？

在 C 的情况下，这只是风格问题，因为两者都是正确的，但总的来说，我相信更多的人（包括我）更喜欢明确的比较 (ptr == NULL)，如下所示：

C++0x 引入了一个 nullptr 关键字来强调它不仅仅是一个数字或布尔值。
Java 强制进行显式比较 (obj == null) 并且不允许 !obj。

【讨论】：

【解决方案6】：

是的，这是风格问题。 fp == NULL （哎呀，我写了fp = NULL...） 表达的非常清楚和明确，对于那些不熟悉所有C语言曲折的人来说很好。尽管!fp 非常像一个成语和双关语：“fp 有 not(!)hing”。蚂蚁很短。为此，我喜欢!fp。我认为 C 设计者也喜欢这样，否则他们不应该为指针定义 !。 :)

【讨论】：

@thkala：是的。（这就是我不喜欢==的原因：））