c - 对等号和运算符使用宏

Question

最近在 C 语言上刷新了我的自我。从一些博客中，我阅读了诸如“==”和“&&”之类的运算符会导致程序员分别使用“=”和“&”而容易出错，并且程序员花了很多时间来查找和解决问题.

我认为为“==”和“&&”定义宏将解决这个问题。

#define EQ ==
#define AND &&

int main(void) 
{
    int a = 1 , b = 2 ; 

    if(a EQ 1 AND b EQ 2 ){
        //  some statements
    }

}

可读性是否混乱？有没有其他解决方案来解决这个问题？

score 3 · Accepted Answer

就个人而言，我不喜欢触及该语言的基本语法，例如创建宏来替换 C 关键字或运算符。

在这种情况下，它非常简单，并且可能不会改变可读性，但是其他程序员（如果您不是唯一维护代码的人）看到这些宏可能会想为他们认为模棱两可或错误的其他东西创建其他宏易于。

所以我不会在 C 中的关键字/运算符级别支持宏。
但是您可以使用一些编译器选项来显示何时存在歧义，例如

  gcc -Wall prog.c -o prog

Wall启用所有警告（您可以使用 gcc 优化警告）。这取决于您使用的编译器。

例如

  int a=1,b=2;
  if (a = b) { ... }

会给出一个警告，将 gcc 作为带有该-Wall选项的编译器。

score 1 · Accepted Answer

试图重新定义 C 语言总是一个非常糟糕的主意。通过宏替换操作符会使代码对其他 C 程序员不可读。

关于&&意外变成&，我怀疑是不是问题，至少我从来没有遇到过这个问题。标准 C 中已经有替代的逻辑运算符，如果有的话，你应该使用它们。

标头<iso646.h>定义了以下 11 个宏（在左侧），它们扩展为相应的标记（在右侧）：

and     &&
and_eq  &=
bitand  &
bitor   |
compl   ~
not     !
not_eq  !=
or      ||
or_eq   |=
xor     ^
xor_eq  ^=

== 危险的想法是一个非常过时的想法。在 80 年代，困惑的程序员发明了一些晦涩难懂的规则，例如“在进行比较时始终将文字放在变量前面”，即if (0 == var).

避免与此相关的错误的正确方法是避免在条件内赋值。一旦您采用了这种良好的编码风格，就很容易避开此类错误。自 1990 年 Turbo C 发布以来，发现它们一直不是问题。从那时起，当您在 if 语句中进行赋值时，几乎每个编译器都能够警告“可能不正确的赋值”。

在现代编程中，所有专业程序员都使用静态分析器工具来发现各种编译时错误。如果您的编译器由于某种原因无法发现此错误，那么静态分析器肯定会。

所以回答你的问题：是的，它很混乱，使代码更容易出错，可读性更差。

score 1 · Accepted Answer

这是一个坏主意，最好的办法是在激活所有警告标志（-Wall）的情况下进行编译，并确保您可以在没有警告的情况下编译代码

和TDD。它更多的是关于语法的实践

我会推荐这本书“代码完成”

score 0 · Accepted Answer

不，这不是一个特别好的主意。这意味着任何有经验的 C 程序员在阅读您的代码之前都必须找出其含义EQ和AND含义，然后才能阅读您的代码。

当然，==可能容易出错，但恕我直言，解决该问题的最佳方法是（a）在编译器中打开警告，以及（b）小心。

（标准头文件<iso646.h>提供了一个and扩展为的宏&&，但它没有为提供宏==。重点<iso646.h>是支持某些字符由于旧的国家变体字符集而难以使用的系统，而不是提供更具可读性的替代方案.)

score 0 · Accepted Answer

实际上，我认为这里没有问题。如果检测到可疑内容，任何现代编译器都会发出警告。

5 回答 5