将赋值操作结果用于条件判断：仅为代码混淆还是存在性能收益？

嘿，这个问题问得相当务实——很多开发者都会纠结这种紧凑写法的性能收益和编码规范问题，咱们来一步步拆解清楚：

性能层面：现代编译器下无差异 #

首先明确结论：在开启常规优化（比如GCC/Clang的-O2、MSVC的/O2）的情况下，你给出的两段C++代码生成的机器码完全一致，不存在任何性能差异。

原因在于现代编译器的数据流分析能力：优化器会识别到第一段代码中，b = a%2之后立刻进行if (b != 0)的判断，且中间没有任何对b的修改操作。它会自动将这两步合并成和第二段代码完全相同的逻辑——计算a%2并赋值给b，同时直接用这个结果做条件判断，不会产生额外的内存读写或CPU周期消耗。

你可以自己验证一下：用编译器的-S参数（GCC/Clang）或者查看汇编输出的功能（MSVC），对比两段代码的汇编指令，会发现它们几乎一模一样。

如果是未开启优化的 debug 模式，第二段代码理论上会少一次对b的读取操作（直接用赋值的结果判断，而不是再从内存读一次b），但这种场景下没人会关心性能——debug 模式本身就是为了调试，性能不是优先级。

编码实践层面：争议性但并非绝对不良 #

这种“在条件中直接赋值”的写法，算不算不良编码实践，其实分场景：

• 合理场景：在循环读取输入的场景中（比如经典的while ((c = getchar()) != EOF)），这种写法非常紧凑，是业界广泛接受的惯用写法，几乎不会有人觉得有问题。
• 需要谨慎的场景：在普通的if判断中，这种写法容易被新手误判为==的笔误，增加了代码的理解成本。如果你的团队有明确的编码规范禁止这种写法（比如部分大厂风格指南不推荐在if中直接赋值，除非用额外括号明确标注），那最好遵守规范，避免风格不统一。

对你推测的补充 #

你的猜想其实很准确：

• 第二段代码在极端老旧或未优化的编译器下，可能会有极其微小的性能收益，但在现代开发环境中完全可以忽略；
• 只要编译器开启了常规优化，两段代码的性能就完全等效；
• 可读性和团队规范才是你需要优先考虑的因素。

内容的提问来源于stack exchange，提问作者4xel