千
千中元
Unregistered / Unconfirmed
GUEST, unregistred user!
5、下面是C语言中两种if语句判断方式。请问哪种写法更好？为什么？
int n;
if (n == 10) // 第一种判断方式
if (10 == n) // 第二种判断方式
int n;
if (n == 10) // 第一种判断方式
if (10 == n) // 第二种判断方式
您正在使用一款已经过时的浏览器！部分功能不能正常使用。
请尝试升级或使用 其他浏览器。
请尝试升级或使用 其他浏览器。
C
cheka
Unregistered / Unconfirmed
GUEST, unregistred user!
第二种
在写判断语句的时候很容易漏写一个“=”
比如把
if (n == 10) { }
写成
if (n = 10) { }
而在C中 “n = 10” 是有返回值的， 这个返回值是10， 于是原语句相当于
if ( 10 ) { } ,即条件永远为真，{ } 内的代码始终能够得到执行，当这样的
错误深深埋藏在代码当中，真是很让人头痛的，如果换成第二种写法
if ( 10 == n ) { } 及时少写一个"=", 编译器就会报错，省得在运行期调试
得死去活来。
在写判断语句的时候很容易漏写一个“=”
比如把
if (n == 10) { }
写成
if (n = 10) { }
而在C中 “n = 10” 是有返回值的， 这个返回值是10， 于是原语句相当于
if ( 10 ) { } ,即条件永远为真，{ } 内的代码始终能够得到执行，当这样的
错误深深埋藏在代码当中，真是很让人头痛的，如果换成第二种写法
if ( 10 == n ) { } 及时少写一个"=", 编译器就会报错，省得在运行期调试
得死去活来。
飞
飞龙在天
Unregistered / Unconfirmed
GUEST, unregistred user!
同意楼上。
如果形成第二中写法的习惯以后，万一不小心把 == 少写了一个 = ，就可以在编译的时候
检查出来。
如果形成第二中写法的习惯以后，万一不小心把 == 少写了一个 = ，就可以在编译的时候
检查出来。
R
robertcool
Unregistered / Unconfirmed
GUEST, unregistred user!
我觉得第一种好
T
TYZhang
Unregistered / Unconfirmed
GUEST, unregistred user!
第一种好，因为第一种符合程序的读写习惯，如果仅仅是为了发现错误，第一种在编译时，
会有警告提示。
会有警告提示。
H
htw
Unregistered / Unconfirmed
GUEST, unregistred user!
第一种好，因为它可读性强，只有一个等号编译时会出现warning
S
sslxml
Unregistered / Unconfirmed
GUEST, unregistred user!
见仁见智吧，我倾向于第一种，虽然第二种某某大师建议过，我也试过，但写程序时
写者写着就成第一种了，结果还要把第二种的改过来，唉！
我同意TYZhang, htw: 通过编译警告其实也一样可以辅助查错的，编译时最好设到4级。
写者写着就成第一种了，结果还要把第二种的改过来，唉！
我同意TYZhang, htw: 通过编译警告其实也一样可以辅助查错的，编译时最好设到4级。
郭
郭玉梁
Unregistered / Unconfirmed
GUEST, unregistred user!
第一种好，符合逻辑习惯。
S
sunshan
Unregistered / Unconfirmed
GUEST, unregistred user!
我也习惯第一种
H
honestman
Unregistered / Unconfirmed
GUEST, unregistred user!
第一种好，起码看上去顺眼啊！！！
C
cheka
Unregistered / Unconfirmed
GUEST, unregistred user!
VC6 中，编译选项设为四级 确实能对第一种情况的出现的疏忽报警，可是同时还会
新增不少其他的警告，相当一部分还来自于MFC的源码，我不知道是不是每个人都有
足够的慧眼从一大堆 WARNING 中发现自己隐藏的错误。
很多人说第一种好，看上去顺眼，太对了，这就是导致错误的根源，为什么 x == 10
比 10 == x 顺眼？ 因为它更像 x = 10,因此也更容易写成x = 10。
至于说第一种更符合逻辑，这就无从谈起，在逻辑上A == B 完全等价 B == A。谁也
不比谁更符合逻辑。
谈到习惯呢，我想习惯应该迁就规范， 而不是相反， 当然第二种写法不是强制的，
但是既然能给编程带来好处，为什么不试着将之培养成习惯。关于编程风格的书中，
Scott Meyers写的《Effecitve C++ 》和 《More Effective C++》堪称经典，但除
非是有许多年功力的老鸟，第一次看这两本书时没几个人会觉得其中的风格顺眼或者
说符合自己的习惯----毕竟，习惯并不等同于经验。
新增不少其他的警告，相当一部分还来自于MFC的源码，我不知道是不是每个人都有
足够的慧眼从一大堆 WARNING 中发现自己隐藏的错误。
很多人说第一种好，看上去顺眼，太对了，这就是导致错误的根源，为什么 x == 10
比 10 == x 顺眼？ 因为它更像 x = 10,因此也更容易写成x = 10。
至于说第一种更符合逻辑，这就无从谈起，在逻辑上A == B 完全等价 B == A。谁也
不比谁更符合逻辑。
谈到习惯呢，我想习惯应该迁就规范， 而不是相反， 当然第二种写法不是强制的，
但是既然能给编程带来好处，为什么不试着将之培养成习惯。关于编程风格的书中，
Scott Meyers写的《Effecitve C++ 》和 《More Effective C++》堪称经典，但除
非是有许多年功力的老鸟，第一次看这两本书时没几个人会觉得其中的风格顺眼或者
说符合自己的习惯----毕竟，习惯并不等同于经验。
飞
飞龙在天
Unregistered / Unconfirmed
GUEST, unregistred user!
cheka兄，精彩！
S
sslxml
Unregistered / Unconfirmed
GUEST, unregistred user!
to cheka:
尽管你说的听起来很有道理，但是我还是不敢苟同，原因如下：
1、如果这种定义（形如：10 == A）真的可以应用于所有的C++代码的，同时增加派错能力
的化，为什么 MFC 本身不这样写？既然我们要写 MFC 的应用程序，为什么不遵循 MFC
的代码书写规范？虽然，“习惯应该迁就规范”但也要分情况，同样的规范本身就有很多
种，我看过其他的规范，包括（openssl，ACE，Mozilla ……），没有哪个规范要求要这
样判断常量相等。
2、在实际的编程中，往往直接将常数与变量比较的情况并不多，至少这样写是欠妥的，大
多数的情况是定义一个常量，如下：
#define MY_CONST 10
然后，在程序中：
if ( A == MY_CONST ) {...}
而同样的情况下，如果程序写成：
if (MY_CONST == A) {} 会给人什么样的错觉呢？
3、虽然“习惯并不等同于经验”，但是程序中大多数错误是在习惯中排查出的。这种逆
思维习惯的编码方式虽然可以辅助派错，但它对人的思维习惯有所影响，可就利弊参半了。
尽管你说的听起来很有道理，但是我还是不敢苟同，原因如下：
1、如果这种定义（形如：10 == A）真的可以应用于所有的C++代码的，同时增加派错能力
的化，为什么 MFC 本身不这样写？既然我们要写 MFC 的应用程序，为什么不遵循 MFC
的代码书写规范？虽然，“习惯应该迁就规范”但也要分情况，同样的规范本身就有很多
种，我看过其他的规范，包括（openssl，ACE，Mozilla ……），没有哪个规范要求要这
样判断常量相等。
2、在实际的编程中，往往直接将常数与变量比较的情况并不多，至少这样写是欠妥的，大
多数的情况是定义一个常量，如下：
#define MY_CONST 10
然后，在程序中：
if ( A == MY_CONST ) {...}
而同样的情况下，如果程序写成：
if (MY_CONST == A) {} 会给人什么样的错觉呢？
3、虽然“习惯并不等同于经验”，但是程序中大多数错误是在习惯中排查出的。这种逆
思维习惯的编码方式虽然可以辅助派错，但它对人的思维习惯有所影响，可就利弊参半了。
C
creation-zy
Unregistered / Unconfirmed
GUEST, unregistred user!
to cheka:
>至于说第一种更符合逻辑，这就无从谈起，在逻辑上A == B 完全等价 B == A。谁也不比谁更符合逻辑。
如果纯粹的从数学推理上来说，您的说法完全正确。问题是写程序的是人，而人们的思维习惯一般是
这样的：“如果x等于10，就做...”，我想一般人在思考的时候不会想：“如果10等于x，就做...”吧。
高级语言的特点就是接近自然语言（哦，不对——C语言不是高级语言）。
>习惯应该迁就规范
如果“规范”与我的思维习惯相抵触，我会选择后者。C语言太...了，有这个问题，在Pascal中就
不存在（不会有人多此一举，写成 if x:=10 then
... 吧）。
>至于说第一种更符合逻辑，这就无从谈起，在逻辑上A == B 完全等价 B == A。谁也不比谁更符合逻辑。
如果纯粹的从数学推理上来说，您的说法完全正确。问题是写程序的是人，而人们的思维习惯一般是
这样的：“如果x等于10，就做...”，我想一般人在思考的时候不会想：“如果10等于x，就做...”吧。
高级语言的特点就是接近自然语言（哦，不对——C语言不是高级语言）。
>习惯应该迁就规范
如果“规范”与我的思维习惯相抵触，我会选择后者。C语言太...了，有这个问题，在Pascal中就
不存在（不会有人多此一举，写成 if x:=10 then
... 吧）。
C
cheka
Unregistered / Unconfirmed
GUEST, unregistred user!
我并没有说 第二种写法一定是规范，可是如果不属于规范（注意，不属于
不代表违背，好像也没有规范要求使用第一种写法）就没有使用的必要了么
Scott Mayers 要求C++程序中所有的常量定义都用const而非 #define xxxxx,
这条也没有被列入规范之中，我觉得他提的很正确，于是我就用。
至于 if (MY_CONST == A) {} 会给人造成错觉，还有您指称这种写法“逆思维
习惯”， 我先前已经提到过了，在比较 A 与 B 两者相等的逻辑里，A和B的位
置完全是等价的，如果我用自然语言说 MY_CONST 和 A相等，你会觉得有逆“思
维习惯”么？我想不会，所以毛病并不出在这种写法上，而是总有人会情不自禁
把(MY_CONST == A) 和 (MY_CONST = A) （而后者确实有逆逻辑）联系起来，这
就是程序出错的源头。
当然pascal里不会有这样的问题，Java里也没有。
在这个小问题上纠缠了不少时间，希望不会被误解为抬杠，我承认每个人有适宜
自己的编程风格，如果你习惯第一种写法，而且也不会出错，很好，我没有任何
强加于人的意思。 但是对许多 C 和 C++ 的初学者来说，试着使用第二种写法，
只要能养成习惯，绝对没有害处，况且这种习惯的培养难度相对于整个C和C++学
习生涯根本算不了什么，至少我个人从发现这种风格到自觉使用，没有超过一个
星期。
把问题结束吧。
千
千中元
Unregistered / Unconfirmed
GUEST, unregistred user!
不细分了
千
千中元
Unregistered / Unconfirmed
GUEST, unregistred user!
多人接受答案了。
Similar threads
- 回复
- 4
- 查看
- 4K