C中if()条件内==(!=)运算符的LHS或RHS中的MACRO?
MACRO in LHS or RHS of == (!=) operator inside if() condition in C?
这是我在分析大型代码库时的观察结果。这是示例代码
/*comparing received RAT(it may be 2G/3G/4G) Type from ip packet with numeric value */
if(pBearer.data.recv.rat_recv == 1)
{
rrc.send_conn.rat_type = MY_GERAN; /* setting RAT as GERAN(enumerated value) i.e 2G */
/* further processing of packet */
}
这是代码审阅者的评论
As per coding standard, we should use MACRO instead of numeric value
as some time we may use =
instead of ==
.
它被解析为
if(pBearer.data.recv.rat_recv == DB_RAT_GERAN) /* DB_RAT_GERAN is a macro defined somewhere in header file */
{
rrc.send_conn.rat_type = MY_GERAN; /* setting RAT as GERAN i.e 2G */
/* further processing of packet */
}
这是正确的,因为有时人们可能会错误地使用 =
而不是像
这样的 ==
if(pBearer.data.recv.rat_recv = 1) { /* always set RAT as 2G */ }
并且编译器不会产生任何警告(好的编译器,可能是,但几乎没有人会分析 make
或 build
结果,直到它崩溃)或类似的错误 & 它会创建一个问题。
现在我有古玩了,可以用like
if(DB_RAT_GERAN == pBearer.data.recv.rat_recv)
而不是
if(pBearer.data.recv.rat_recv == DB_RAT_GERAN)
我更喜欢在比较运算符的左侧 上使用 MACRO 而不是右侧,因为在最坏的情况下,如果错误地使用 =
代替 ==
如下所示
if(DB_RAT_GERAN = pBearer.data.recv.rat_recv){ }
编译器产生一个非常有意义的错误,如
error: lvalue required as left operand of assignment
但是这个
if(pBearer.data.recv.rat_recv = DB_RAT_GERAN) { }
干脆走开。
建议使用以上两者中的哪一个或什至更好的技术并做任何事情C
标准说的是相同的,即 MACRO 应该在检查中的比较运算符的 LHS 或 RHS 端使用?
使用 if (a == 5)
还是 if (5 == a)
很大程度上取决于风格。 C 标准没有说明有关条件语句的推荐用法。
虽然后者(通常称为 "Yoda Conditionals")实际上确实防止错误地使用 =
而不是 ==
(并且正是您提到的代码审查评论是说的),不过这种风格读起来不是很方便。
现在大多数编译器都会在您执行前者时发出警告。特别是,如果您使用 -Wall
,gcc 将对此发出警告,而 MSVC 将使用 /W4
发出警告。只要您将警告级别设置得足够高(您 总是 应该)并将警告视为错误(-Werror
用于 gcc,/WX
用于 MSVC),那么事情像这样不要错过,我建议使用这种风格,以提高可读性和捕捉这种情况的工具。
这是我在分析大型代码库时的观察结果。这是示例代码
/*comparing received RAT(it may be 2G/3G/4G) Type from ip packet with numeric value */
if(pBearer.data.recv.rat_recv == 1)
{
rrc.send_conn.rat_type = MY_GERAN; /* setting RAT as GERAN(enumerated value) i.e 2G */
/* further processing of packet */
}
这是代码审阅者的评论
As per coding standard, we should use MACRO instead of numeric value as some time we may use
=
instead of==
.
它被解析为
if(pBearer.data.recv.rat_recv == DB_RAT_GERAN) /* DB_RAT_GERAN is a macro defined somewhere in header file */
{
rrc.send_conn.rat_type = MY_GERAN; /* setting RAT as GERAN i.e 2G */
/* further processing of packet */
}
这是正确的,因为有时人们可能会错误地使用 =
而不是像
==
if(pBearer.data.recv.rat_recv = 1) { /* always set RAT as 2G */ }
并且编译器不会产生任何警告(好的编译器,可能是,但几乎没有人会分析 make
或 build
结果,直到它崩溃)或类似的错误 & 它会创建一个问题。
现在我有古玩了,可以用like
if(DB_RAT_GERAN == pBearer.data.recv.rat_recv)
而不是
if(pBearer.data.recv.rat_recv == DB_RAT_GERAN)
我更喜欢在比较运算符的左侧 上使用 MACRO 而不是右侧,因为在最坏的情况下,如果错误地使用 =
代替 ==
如下所示
if(DB_RAT_GERAN = pBearer.data.recv.rat_recv){ }
编译器产生一个非常有意义的错误,如
error: lvalue required as left operand of assignment
但是这个
if(pBearer.data.recv.rat_recv = DB_RAT_GERAN) { }
干脆走开。
建议使用以上两者中的哪一个或什至更好的技术并做任何事情C
标准说的是相同的,即 MACRO 应该在检查中的比较运算符的 LHS 或 RHS 端使用?
使用 if (a == 5)
还是 if (5 == a)
很大程度上取决于风格。 C 标准没有说明有关条件语句的推荐用法。
虽然后者(通常称为 "Yoda Conditionals")实际上确实防止错误地使用 =
而不是 ==
(并且正是您提到的代码审查评论是说的),不过这种风格读起来不是很方便。
现在大多数编译器都会在您执行前者时发出警告。特别是,如果您使用 -Wall
,gcc 将对此发出警告,而 MSVC 将使用 /W4
发出警告。只要您将警告级别设置得足够高(您 总是 应该)并将警告视为错误(-Werror
用于 gcc,/WX
用于 MSVC),那么事情像这样不要错过,我建议使用这种风格,以提高可读性和捕捉这种情况的工具。