今天看了一下C语言大全（第四版），在P44看到这么一行话
if (b != 0) printf("%d\n", a / b);则是冗余且潜在低效的，这不是一种好风格。因为b足以控制if语句，没有必要通过与零比较去测试它。
书上面是使用if (b)，上面这段话是说这种方式不好，不应该使用这种方式。
我记得以前看林锐的高质量C/C++编程时好象说只有把一个变量当成bool型时，就应该使用if (b)这种形式，否则就应该使用if (b != 0)这种方法。
还有我在写代码的时候，指针比较习惯这么写if (NULL != p)，但是我老大看到了就说我这么写是错的，到底怎么写好了？
emacsnw 回复于：2007-04-06 16:25:13
引用：原帖由 剑击长空 于 2007-4-6 00:21 发表
今天看了一下C语言大全（第四版），在P44看到这么一行话
if (b != 0) printf("%d\n", a / b);则是冗余且潜在低效的，这不是一种好风格。因为b足以控制if语句，没有必要通过与零比较去测试它。
书 ...
偶觉得 if (b) 好点，少打几个字，也不容易出错，不管b是bool还是int或是指针。
Edengundam 回复于：2007-04-06 16:32:55
p != NULL /* 见得多些 */
NULL != p /* 也见过 */
个人观点:
数值型, 我认为一定要写i == 0,i != 0的样子, 这样明确i的特点.
可以宏定义bool变量, 这时候, 直接if (bool) 我觉得合适.
指针感觉还是明确写出NULL好些...当然不写我觉得没有什么..
epegasus 回复于：2007-04-06 16:35:37
我就不明白了,当b是指针的时候也可以这样判断吗?比如malloc申请内存的失败时候不是返回NULL吗?而NULL确不一定是0,请楼上的解惑
MMMIX 回复于：2007-04-06 17:05:53
写代码的时候, 不但要考虑效率, 而且要考虑代码的可读性, 可维护性, 以及代码风格的约定等等. 对程序效率影响最大的往往是数据结构和算法的选择, 而不是具体的编码细节, 例如用 if(p) 而不是 if(p == NULL), 等等.
在 C 中, 检测空指针(null pointer)的时候, 用 if(p) 或者 if(p == NULL) 效果都是一样的, 因为空指针在 bool context 中就代表 false. 至于采用哪种写法就看各人习惯(如果是从头开始写的话)或者是代码风格的约定(如果是修改别人的代码).
MMMIX 回复于：2007-04-06 17:12:23
引用：原帖由 剑击长空 于 2007-4-6 16:21 发表
还有我在写代码的时候，指针比较习惯这么写if (NULL != p)，但是我老大看到了就说我这么写是错的，
你可以请你的老大详细解释下为什么这么写是错误的, 当然前提是 p 是一个指针.
剑击长空 回复于：2007-04-06 17:15:13
引用：原帖由 MMMIX 于 2007-4-6 17:05 发表
写代码的时候, 不但要考虑效率, 而且要考虑代码的可读性, 可维护性, 以及代码风格的约定等等. 对程序效率影响最大的往往是数据结构和算法的选择, 而不是具体的编码细节, 例如用 if(p) 而不是 if(p == NULL), 等等 ...
MMMIX说的有道理！
但是我们公司同一个人写出来的都是不一样的，在一个函数中有时if (p)，有时if (p == NULL)，{}括号也是一样
if () {
}
和
if ()
{
}当一个文件代码量小时，还没什么问题，但是有那么四五千行看起来就吃力了
我现在在维护一个代码，有时候代码中出现
if (b) b = a; {
}看到这种写法我就晕了，出问题了，总是疑惑写这代码的人是不是写错了。
公司有一份编程规范，但几乎没人遵守。搞得维护的人很吃力。
Edengundam 回复于：2007-04-06 17:17:40
引用：原帖由 剑击长空 于 2007-4-6 17:15 发表
MMMIX说的有道理！
但是我们公司同一个人写出来的都是不一样的，在一个函数中有时if (p)，有时if (p == NULL)，{}括号也是一样
if () {
}
和
if ()
{
}当一个文件代码量小时，还没什么问题，但是有那么 ...
代码检查, 版本控制做的不好.
剑击长空 回复于：2007-04-06 17:19:47
引用：原帖由 MMMIX 于 2007-4-6 17:12 发表
你可以请你的老大详细解释下为什么这么写是错误的, 当然前提是 p 是一个指针.
p当然是指针，当时也没问为什么错的（不敢问，老大脾气火暴，随便我问什么，总是挨骂，不知道是不是自己说话方式有问题），看我们老大写的代码有时用if (p)，有时用if (p == NULL)
net_robber 回复于：2007-04-06 17:21:16
引用：原帖由 剑击长空 于 2007-4-6 17:15 发表
......
公司有一份编程规范，但几乎没人遵守。搞得维护的人很吃力
这个说的很好啊
net_robber 回复于：2007-04-06 17:21:49
没有规矩，不成方圆
soul_of_moon 回复于：2007-04-06 17:26:19
引用：原帖由 Edengundam 于 2007-4-6 16:32 发表
p != NULL /* 见得多些 */
NULL != p /* 也见过 */
个人观点:
数值型, 我认为一定要写i == 0,i != 0的样子, 这样明确i的特点.
可以宏定义bool变量, 这时候, 直接if (bool) 我觉得合适.
指针感觉还是明 ...
现在都用
if(p)//不为NULL，0等
tyc611 回复于：2007-04-06 17:26:36
引用：原帖由 Edengundam 于 2007-4-6 16:32 发表
p != NULL /* 见得多些 */
NULL != p /* 也见过 */
个人观点:
数值型, 我认为一定要写i == 0,i != 0的样子, 这样明确i的特点.
可以宏定义bool变量, 这时候, 直接if (bool) 我觉得合适.
指针感觉还是明 ...
赞同
epegasus 回复于：2007-04-06 17:31:15
引用：原帖由 剑击长空 于 2007-4-6 17:19 发表
p当然是指针，当时也没问为什么错的（不敢问，老大脾气火暴，随便我问什么，总是挨骂，不知道是不是自己说话方式有问题），看我们老大写的代码有时用if (p)，有时用if (p == NULL)
这就不好说什么了,世界大了什么鸟都有
MMMIX 回复于：2007-04-06 17:32:30
引用：原帖由 剑击长空 于 2007-4-6 17:19 发表
p当然是指针，
如果 p 是指针的话, 写成 if(p) 或 if(p == NULL) 或 if(NULL == p) 都没有问题. 我想你老大说你错了, 要么是他/她当时脑袋短路:em02:, 要么是你记错了, 要么是和上下文有关(也许应该用 == 而你却用成了 != 等等). 总之, 有很多种可能.:mrgreen:
[ 本帖最后由 MMMIX 于 2007-4-6 17:33 编辑 ]
MMMIX 回复于：2007-04-06 17:38:38
引用：原帖由 剑击长空 于 2007-4-6 17:15 发表
但是我们公司同一个人写出来的都是不一样的，在一个函数中有时if (p)，有时if (p == NULL)，{}括号也是一样
if () {
}
和
if ()
{
}当一个文件代码量小时，还没什么问题，但是有那么四五千行看起来就吃力了
我现在在维护一个代码，有时候代码中出现
if (b) b = a; {
}看到这种写法我就晕了，出问题了，总是疑惑写这代码的人是不是写错了。
公司有一份编程规范，但几乎没人遵守。搞得维护的人很吃力。
开发人员素质参差不齐是现实, 哪个公司都存在, 只是严重程度不同罢了. 碰到这种情况, 只能是自己想开点了...
yarco3 回复于：2007-04-06 17:39:42
偶觉得指针的时候,
if (p != NULL)
//好看点
不是指针就用
if (p)
//判断
总之, 偶觉得好看不好看很重要...
所以一个人帅不帅也蛮重要的...倒不是说外表...
主要容易理解, 一看就知道偶是个好人...
也就不会为难我了...
剑击长空 回复于：2007-04-06 17:58:52
引用：原帖由 MMMIX 于 2007-4-6 17:32 发表
如果 p 是指针的话, 写成 if(p) 或 if(p == NULL) 或 if(NULL == p) 都没有问题. 我想你老大说你错了, 要么是他/她当时脑袋短路:em02:, 要么是你记错了, 要么是和上下文有关(也许应该用 == 而你却用成了 != 等 ...
他当时用笔在纸上写了要用if (p)，然后又写个if (p != NULL)接着又在上面打了个叉，说这个是错的
飞灰橙 回复于：2007-04-06 21:24:52
这种效率问题根本不用考虑，当做编译器的人是白痴吗？
Iamlangue 回复于：2007-04-06 21:33:37
if (a == 1); /* 这样是不是容易和 a = 1 混淆起来？*/
if (1 == a); /* 运算符左边的值是常数，赋值给常数是非法的，编译器会立即报告错误。这样还会混淆吗？*/
飞灰橙 回复于：2007-04-06 21:37:06
引用：原帖由 Iamlangue 于 2007-4-6 21:31 发表
if (a == 1); /* 这样是不是容易和 a = 1 混淆起来？*/
if (1 == a); /* 运算符左边的值是常数，赋值给常数是非法的，编译器会立即给出警告。这样还会混淆吗？*/
仁者见仁, 第二种方式以可读性降低为代价.
if (a = 1)很多编译器也会警告, 所以现在几乎不需要 if (1 == a) 了,
当然如果你写if(1==a)也是很令人欣赏的.
Iamlangue 回复于：2007-04-06 21:42:05
说得很好。只是语言本身有很多不完美的地方，这时候既然不能大刀阔斧地动手对语言进行改革，就得动脑子想办法了。可读性也是个相对的概念，或许更好的方式是对分布于世界各地的C程序员展开调查，注意他们对 a==1 和 1==a 是怎么看的。
飞灰橙 回复于：2007-04-06 21:44:11
引用：原帖由 Iamlangue 于 2007-4-6 21:42 发表
或许更好的方式是对分布于世界各地的C程序员展开调查，注意他们对 a==1 ...
嗯, 有必要到sf随机抽代码, 统计 a == 1 和 1 == a 两种形式出现的频率.
Iamlangue 回复于：2007-04-06 21:45:16
引用：原帖由 飞灰橙 于 2007-4-6 21:37 发表
仁者见仁, 第二种方式以可读性降低为代价.
if (a = 1)很多编译器也会警告, 所以现在几乎不需要 if (1 == a) 了,
当然如果你写if(1==a)也是很令人欣赏的.
另外，我说的是这种情况下编译器报告的错误。
main()
{
int a = 0;
if (1 = a);
}
accelerator 回复于：2007-04-07 01:29:24
这点代码差异不足以引起软件在性能上的损失, 性能基本上还是由架构决定. LZ的问题其实属于编码风格问题, 个人认为编码风格只要一致就可以了. 一致主要是与上下文环境保持一致. 不过我更喜欢写
if (p) {
...
}
Edengundam 回复于：2007-04-07 07:27:01
引用：原帖由 飞灰橙 于 2007-4-6 21:24 发表
这种效率问题根本不用考虑，当做编译器的人是白痴吗？
:mrgreen:哈哈...这句话说得太经典了...有时候性能根本没有我们想象的那么差:m01:
safedead 回复于：2007-04-07 09:35:26
自从俺用上NULL == p, 5 <= n
之后,就再也没有出现把==和=混用的错误了
人难免会犯昏
我的代码里面, 比较时, 常量一律在变量的左边
xcmissyou 回复于：2007-04-07 10:08:46
if(b),if(p)都是规范的写法 啊
NULL!=p也应该没问题吧
flw 回复于：2007-04-07 10:21:27
我有个问题很好奇，
既然我们本来的问题是把 a == 1 写对，不要误写成 a = 1，那么为什么不直接记住这个呢？
难道一个人记得写 1 == a（而不是 a == 1 ）就不记得写 a == 1 （而不是 a = 1）？
就好比一个人每天早上起床之后都要洗脸，可总是忘了洗脖子，于是解决的方法就是以后早上起来以后不洗脸，直接洗澡，那便永远也忘不了洗脖子了。
很奇怪的思维方式。
反正对于我来讲，
我与其时刻提醒自己应该写 1 == a 而不是 a == 1，那还不如时刻提醒自己应该写 a == 1 而不是 a = 1 好了。
bGFuZ3Vl 回复于：2007-04-07 10:22:08
有句话说得好，我们不要做语言的奴隶，而应该让语言为我们奴役。
MMMIX 回复于：2007-04-07 11:05:50
引用：原帖由 flw 于 2007-4-7 10:21 发表
我有个问题很好奇，
既然我们本来的问题是把 a == 1 写对，不要误写成 a = 1，那么为什么不直接记住这个呢？
难道一个人记得写 1 == a（而不是 a == 1 ）就不记得写 a == 1 （而不是 a = 1）？
对头。1 == a 或者 NULL == p 这类的写法总让我感觉有点奇怪，看着有点别扭……
soul_of_moon 回复于：2007-04-07 11:14:46
引用：原帖由 MMMIX 于 2007-4-7 11:05 发表
对头。1 == a 或者 NULL == p 这类的写法总让我感觉有点奇怪，看着有点别扭……
说明你们两个没有养成编程的良好习惯。如果一个project中因为某个地方应该是a==1，而误写成a=1，那需要多少时间去找到这个bug。但是如果你是写成1=a，那么编译的时候就会错误，也就不会有bug。
后者，建议写成if(!p)
飞灰橙 回复于：2007-04-07 11:52:18
引用：原帖由 flw 于 2007-4-7 10:21 发表
我有个问题很好奇，
既然我们本来的问题是把 a == 1 写对，不要误写成 a = 1，那么为什么不直接记住这个呢？
难道一个人记得写 1 == a（而不是 a == 1 ）就不记得写 a == 1 （而不是 a = 1）？
就好比一个人每天早上起床之后都要洗脸，可总是忘了洗脖子，于是解决的方法就是以后早上起来以后不洗脸，直接洗澡，那便永远也忘不了洗脖子了。
很奇怪的思维方式。
反正对于我来讲，
我与其时刻提醒自己应该写 1 == a 而不是 a == 1，那还不如时刻提醒自己应该写 a == 1 而不是 a = 1 好了。
我也这么想！在此点名批评几个聪明过头的做法：
一，1 == a
二，匈牙利表示法 //遗憾的是我们自己的项目组也有这个规定，我不得不配合
三，if/else 后面一定要加{}
四，定义指针随即赋值NULL
五，free指针重新赋值NULL
其中一和二都能导致程序阅读性极大的降低。
四五多半用来修补那些冗长的质量不佳的代码。
其实都对于我们写出优秀的代码于事无补。
bGFuZ3Vl 回复于：2007-04-07 11:56:33
代码风格属于 “宗教信仰”。
Vinge 回复于：2007-04-07 13:41:49
我记得<bug free > 里头就推荐使用if (const==var)这样的写法,可以避免漏写 =号做成的符值，(NULL！=p)我觉得基于同样的原则习惯也是可取的！
flw 回复于：2007-04-07 14:48:41
引用：原帖由 soul_of_moon 于 2007-4-7 11:14 发表
说明你们两个没有养成编程的良好习惯。如果一个project中因为某个地方应该是a==1，而误写成a=1，那需要多少时间去找到这个bug。但是如果你是写成1=a，那么编译的时候就会错误，也就不会有bug。
晕～
同样是习惯，为什么你养成 a == 1 的习惯之后就容易误写为 a=1，而养成 1 == a 的习惯就不用误写为 a=1？
再或者养成 1 == a 的习惯要比养成 a == 1 的习惯更加容易一些？
flw 回复于：2007-04-07 14:50:58
引用：原帖由 飞灰橙 于 2007-4-7 11:52 发表
我也这么想！在此点名批评几个聪明过头的做法：
一，1 == a
二，匈牙利表示法 //遗憾的是我们自己的项目组也有这个规定，我不得不配合
三，if/else 后面一定要加{}
四，定义指针随即赋值NULL
五， ...
你说的匈牙利表示法是指把变量的类型缩写字母写在变量的前面吧？
我也很讨厌这么做——凭什么你写是 iCount 这个变量就一定是整形了？
就算是再好的编译器、打开再多的开关选项，也不会给 double iCount 发任何警告。
flw 回复于：2007-04-07 14:58:46
下面说一下我对于 a == 1 容易误写为 a = 1 的建议：
1，永远不要把赋值运算的作为语句的一部分，包括但不限于将赋值运算的结果当作判断条件，应该用如下的代替方法：
ret = call_foo( ... );
if ( ret .... )
这一点在 Python 里面是强制性的：赋值是语句，而不是运算。
2，gcc 用户在任何时候，都应该打开 -Wall。重视所有的警告，如果的确属于编译器误判的，应该采用等效的、不会产生警告的写法来代替。
3，如果有可能的话，请使用 lint 检查你的程序，但是别忘了给它加一层包装——lint 在缺省情况下太严格了，俗话说虱子多了不痒，所以还不如把那些希望忽略的警告用命令行参数来禁止掉，让那些潜在的危险更明显一些。
MMMIX 回复于：2007-04-07 15:02:13
引用：原帖由 flw 于 2007-4-7 14:50 发表
你说的匈牙利表示法是指把变量的类型缩写字母写在变量的前面吧？
我也很讨厌这么做——凭什么你写是 iCount 这个变量就一定是整形了？
这种命名法是基于这么一种假设：所有现在和将来可能会修改这些代码的人都很了解这种命名法，而且会在所有的代码中前后一致的遵守这种约定。当然，如果这种假设成立，那么无疑不错，看到变量名就知道其类型甚至用法。而实际情况却是，在绝大多数情况下，这种假设都或多或少的不成立，接着混乱就开始出现了……
namei 回复于：2007-04-07 15:04:37
引用：原帖由 剑击长空 于 2007-4-6 16:21 发表
还有我在写代码的时候，指针比较习惯这么写if (NULL != p)，但是我老大看到了就说我这么写是错的，到底怎么写好了？
老大一般都比较固执啊，这没什么错
namei 回复于：2007-04-07 15:09:02
哈哈，程序员可以有自己的风格啊，比如把赋值和判断写到一起的事情，照你这么说连 i += 1 都不适合了？
语言是死的，人是活的
flw 回复于：2007-04-07 15:12:40
引用：原帖由 namei 于 2007-4-7 15:09 发表
[color=red]照你这么说[/color]连 i += 1 都不适合了？
哥们，说话要注意逻辑，请问你是如何“照”的？
soul_of_moon 回复于：2007-04-07 15:16:23
引用：原帖由 flw 于 2007-4-7 15:12 发表
哥们，说话要注意逻辑，请问你是如何“照”的？
不用争了，这本来就是习惯问题。
namei 回复于：2007-04-07 15:16:39
引用：原帖由 flw 于 2007-4-7 15:12 发表
哥们，说话要注意逻辑，请问你是如何“照”的？
原来是斑竹，那就不造次了。这个推论纯属个人臆想。再说代码风格自由，我先下了 :m01:
flw 回复于：2007-04-07 15:21:26
引用：原帖由 namei 于 2007-4-7 15:16 发表
这个推论纯属个人[color=red]臆[/color]想。
“臆”字用的不错，活灵活现，我接受这个道歉。
好了，没事了。
tyc611 回复于：2007-04-07 15:37:09
引用：
1，永远不要把赋值运算的作为语句的一部分，包括但不限于将赋值运算的结果当作判断条件，应该用如下的代替方法：
ret = call_foo( ... );
if ( ret .... )
任何事情无绝对，这得看你的使用环境
就拿C++里面的例子，有如下代码：
Base *basePtr;
// other statements
if (Derived *deirvedPtr = dynamic_cast<Derived*>(basePtr)) {
// use the Derived object
} else {
// use the Base object
}
这段代码的好处是简洁而又安全
flw 回复于：2007-04-07 15:43:08
引用：原帖由 tyc611 于 2007-4-7 15:37 发表
任何事情无绝对，这得看你的使用环境
就拿C++里面的例子，有如下代码：
Base *basePtr;
// other statements
if (Derived *deirvedPtr = dynamic_cast<Derived*>(basePtr)) {
// use th ...
这种情况太多了，但是其后果就是通常没法在标准的 24 * 80 终端上完整地显示一行。
当然了，编程风格问题，属于谁也不能说服谁的问题。
tyc611 回复于：2007-04-07 15:45:00
引用：原帖由 flw 于 2007-4-7 15:43 发表
这种情况太多了，但是其后果就是通常没法在标准的 24 * 80 终端上完整地显示一行。
能说说这个吗？不懂，请教下下
flw 回复于：2007-04-07 15:53:12
引用：原帖由 tyc611 于 2007-4-7 15:45 发表
能说说这个吗？不懂，请教下下
就是说，我个人，强调一下，仅仅是我个人而已。我个人非常不喜欢一个长长的行，到底多长就算长呢？就是说超出了我常用的终端的屏幕宽度。现在的液晶屏大一些了，还好一些，否则长行太难看了。
即使如此，我现在写程序还是从来不把赋值语句作为 if while 等语句的条件。
BTW：一般来说大多数终端的宽度都要超过 79 列，但是因为有缩进，因此可供我们写程序的空间并不是很大。
tyc611 回复于：2007-04-07 16:34:42
引用：原帖由 flw 于 2007-4-7 15:53 发表
就是说，我个人，强调一下，仅仅是我个人而已。我个人非常不喜欢一个长长的行，到底多长就算长呢？就是说超出了我常用的终端的屏幕宽度。现在的液晶屏大一些了，还好一些，否则长行太难看了。
即使如此，我现在 ...
哦，了解了，其实现在用C++/Java编写的程序有很多语句是很长的，没办法避免
flw 回复于：2007-04-07 16:37:21
引用：原帖由 tyc611 于 2007-4-7 16:34 发表
哦，了解了，其实现在用C++/Java编写的程序有很多语句是很长的，没办法避免
这就又归结到命名法的问题了……
如果不是因为命名的原因，很多代码行都可以短很多……
白天晒太阳 回复于：2007-04-07 16:52:53
引用：原帖由 flw 于 2007-4-7 15:53 发表
就是说，我个人，强调一下，仅仅是我个人而已。我个人非常不喜欢一个长长的行，到底多长就算长呢？就是说超出了我常用的终端的屏幕宽度。现在的液晶屏大一些了，还好一些，否则长行太难看了。
即使如此，我现在 ...
:em18:嗯还应该考虑一下以后维护这些代码时使用的显示终端的宽度:em18:
lijay 回复于：2007-04-07 20:41:09
引用：原帖由 飞灰橙 于 2007-4-7 11:52 发表
我也这么想！在此点名批评几个聪明过头的做法：
一，1 == a
二，匈牙利表示法 //遗憾的是我们自己的项目组也有这个规定，我不得不配合
三，if/else 后面一定要加{}
四，定义指针随即赋值NULL
五， ...
握手, 握手, 感动, 感动, 终于看到知音了....
你说的5点, 我们公司中了4点(后4点), 为此我和领导争论过无数次了.
特别是定义指针随即赋NULL和匈牙利命名,让我觉得SB到不行...
Edengundam 回复于：2007-04-07 22:02:43
引用：原帖由 lijay 于 2007-4-7 20:41 发表
握手, 握手, 感动, 感动, 终于看到知音了....
你说的5点, 我们公司中了4点(后4点), 为此我和领导争论过无数次了.
特别是定义指针随即赋NULL和匈牙利命名,让我觉得SB到不行...
对于使用某个变量而设置初始值, 有一种情况是, 某些编译器, 比较弱, 可能会报引用未初始化变量的警告. 因此设置初值, 可以避免这个警告.
至于匈牙利命名法, 估计是因为当初的软件没有现在工具这么只能, 追查一个变量的类型要翻很久, 因此不如让变量名字带着类型的缩写.
软件工程发展这么久, 有很多东西都不一定适用了. 当然我认为有时候好习惯, 是可以避免bug. :em02:
[ 本帖最后由 Edengundam 于 2007-4-8 17:47 编辑 ]
antigloss 回复于：2007-04-08 16:32:20
可参考
http://www.c-faq.com/null/index.html
Csky_mxy 回复于：2007-04-08 19:55:11
我认为你的那个b!=0是不好的，因为不知道b是int 还是float,或者是指针.如果是float的话，这样显然不好。你说是不是呢？
还有，指针时是是否是0来判断的，所以，我觉得你这个程序不严谨，当然，你后面是整形输出可以看到，但是这是一种编程风格和细节的把握。：）
还有很多程序员为了避免出错把p==NULL得条件是写成NULL==p是为了避免出错，编译时，如果你是用p==NULL写成了p=NULL是不会报错的，如果用NULL==p得时候，如果你写成了NULL=p的话，会报错的。
关于判断表达式，if()括号中的比较bool和int 和float的类型要定义清楚，不要用单纯一个字母来定义b==0,这样的话，肯定是不如流的新手写法。：）
而申请完空间后，需要断言一下子，这样才是完整的处理吧，个人浅见。
[ 本帖最后由 Csky_mxy 于 2007-4-8 20:02 编辑 ]
exir 回复于：2007-04-08 23:12:16
我再建议一次，使用-Werror，可以避免很多隐患。
匈牙利命名法对于种类繁多的类型和自定义类型根本无法清晰表示。
他的另一大害处就是变量改变类型时需要改变变量名字，
虽然现在软件的全局替换功能强大，还是让人很不爽，感觉容易出问题。
flw 回复于：2007-04-08 23:13:16
引用：原帖由 exir 于 2007-4-8 23:12 发表
我再建议一次，使用-Werror，可以避免很多隐患。
匈牙利命名法对于种类繁多的类型和自定义类型根本无法清晰表示。
他的另一大害处就是变量改变类型时需要改变变量名字，
虽然现在软件的全局替换功能强大，还是 ...
re
flw2 回复于：2007-04-08 23:35:31
如果是一个计数值，我肯定不会用 !p 这是非常糟糕的。
如果是一个done表示只做一遍，我肯定不会显示的用0，通常是if(!done) doit;
这些好像就是为了可读性，有人喜欢 NULL != p
我讨厌死了，我总觉得那是外行写的代码，我看过的好的代码（开源）有很多这样的例子，我不相信鬼话（有写被认为“很好”的书上就有），只是照抄
flw2 回复于：2007-04-08 23:38:08
引用：原帖由 飞灰橙 于 2007-4-7 11:52 发表
我也这么想！在此点名批评几个聪明过头的做法：
一，1 == a
二，匈牙利表示法 //遗憾的是我们自己的项目组也有这个规定，我不得不配合
三，if/else 后面一定要加{}
四，定义指针随即赋值NULL
五， ...
这个我很喜欢，确实是多于的，而且都会减少可读性，比如
char * p;
p = NULL;
p = malloc
这简直太烂了
flw2 回复于：2007-04-08 23:40:23
引用：原帖由 soul_of_moon 于 2007-4-7 11:14 发表
说明你们两个没有养成编程的良好习惯。如果一个project中因为某个地方应该是a==1，而误写成a=1，那需要多少时间去找到这个bug。但是如果你是写成1=a，那么编译的时候就会错误，也就不会有bug。
后者，建议写成 ...
熟悉了应该是不会的，就好比我的名字是3个字，我从来没有在需要名字的地方只写2个字或者4个字，理由是同样的。
飞灰橙 回复于：2007-04-08 23:54:56
美女市长，老大你的帖子怎么不见牢？
flw 回复于：2007-04-08 23:56:05
引用：原帖由 飞灰橙 于 2007-4-8 23:54 发表
美女市长，老大你的帖子怎么不见牢？
发现语言有歧义，改了几次，还是有歧义，不如删了。
MMMIX 回复于：2007-04-09 00:16:12
引用：原帖由 flw2 于 2007-4-8 23:38 发表
这个我很喜欢，确实是多于的，而且都会减少可读性，比如
char * p;
p = NULL;
p = malloc
这简直太烂了
这纯粹就是多次一举，而且在某些编译器中会导致警告。例如在 Plan 9 的 8c 中如果打开警告，编译时会警告说 "set and not used"
yuanchengjun 回复于：2007-04-09 09:33:58
这种，适合人看，值放在前面，防止不小心写了一个等号。
if (0 == p)
{
...
}
这种适合机器执行，应该比上面那个快一点点。
if (!p)
{
...
}
自己决定，喜欢那种用哪种。
剑击长空 回复于：2007-04-09 11:32:53
说来说去，这个问题其实是个人编程习惯的问题，在一个团队中如果保持一致的风格，肯定会提高工作效率，使得代码更容易阅读和维护。
在我们公司虽说有编程规范，但是没有人去遵守，也没人检查你的代码是否符合公司的编程规范。所以这个编程规范最后成了一纸空文。
现在我看我们小组的其他同事的代码或以前的同事写的代码，都需要事先排版一下再看，不然实在是看不下去。同一个人的代码在同一个文件中的风格都不是一样的，代码又写的很长很长，一行上150个字符的实在太多，最长的我见过700多的了。其中还有宏定义，最初写的人定义了一个宏，但没有注明这个宏是干什么的，另外一个同事在修改这个文件时，看到这个宏了，仅从字面意义上理解一下这个宏，然后就想当然的认为这个宏是干什么的，然后自己又接着用这个宏在来添加代码，这么来来去去，最终这个宏的原意是什么都不知道了，现在我在维护的时候，只好想办法来消除这些宏。
cooleaf 回复于：2007-04-10 14:07:53
引用：原帖由 飞灰橙 于 2007-4-7 11:52 发表
我也这么想！在此点名批评几个聪明过头的做法：
一，1 == a
二，匈牙利表示法 //遗憾的是我们自己的项目组也有这个规定，我不得不配合
三，if/else 后面一定要加{}
四，定义指针随即赋值NULL
五， ...
反对第三条，
第四条我个人觉得int *p = NULL;是很好的习惯，当然
int *p;
p = NULL;
很让鄙夷。
jaffaz 回复于：2007-04-12 08:41:51
我也有一段时间写过
if (1 == a)
但前后不到一个月，又改回来了。总觉得不符合自己的思维习惯。
也没觉得 if (a == 1) 有什么不好。
若真要在条件判断里面来个赋值的话，那也是 if ((a = b) == 1)。
个人认为不要经常改变自己的编码习惯（公司有编码风格约定除外）
flw2 回复于：2007-04-12 12:28:03
引用：原帖由 cooleaf 于 2007-4-10 14:07 发表
反对第三条，
第四条我个人觉得int *p = NULL;是很好的习惯，当然
int *p;
p = NULL;
很让鄙夷。
我看到很多代码都不是你那样写，没有必要。
除非跟这个一样：
int find = 0;
while(!feof(fp)) {
...
if (*) {
find = 1;
break;
}
}
否则可读性更差，比如
struct type * p = NULL;
for(p=head;)
NULL显然是多余的，
litao1227 回复于：2007-04-12 14:48:00
引用：原帖由 flw 于 2007-4-7 15:21 发表
“臆”字用的不错，活灵活现，我接受这个道歉。
好了，没事了。
估计是不小心打错了
呵呵:wink::wink:
beepbug 回复于：2007-04-12 15:04:50
引用：原帖由 剑击长空 于 2007-4-6 16:21 发表
今天看了一下C语言大全（第四版），在P44看到这么一行话
if (b != 0) printf("%d\n", a / b);则是冗余且潜在低效的，这不是一种好风格。因为b足以控制if语句，没有必要通过与零比较去测试它。
书上面是使用if (b)，上面这段话是说这种方式不好，不应该使用这种方式。
我记得以前看林锐的高质量C/C++编程时好象说只有把一个变量当成bool型时，就应该使用if (b)这种形式，否则就应该使用if (b != 0)这种方法。
还有我在写代码的时候，指针比较习惯这么写if (NULL != p)，但是我老大看到了就说我这么写是错的，到底怎么写好了？
if (b != 0)、if (b)、if (NULL != p)，都没错，如果分别用在数值、逻辑、指针上。
jwzhang 回复于：2007-04-13 11:37:48
有个了的错。他只不过看有些高人那么写罢了。每种方法都可以，而且现在的编译器最后生产的汇编码也一样。好坏只在看问题的角度不一样。林锐是从维护和理解角度，C++之父是从语言本身角度，还有些高人各自横竖斜看罢了。
《大规模C++程序设计》也避开了这个问题，觉得没有结果，对风格问题不做很严格的约束。
如果你的老大太强势，顺他意就可以了，没有实质好坏和原因——看问题的角度差异罢了。
唉！人生啊！....
writer15 回复于：2007-04-16 00:54:01
引用：原帖由 MMMIX 于 2007-4-6 17:05 发表
写代码的时候, 不但要考虑效率, 而且要考虑代码的可读性, 可维护性, 以及代码风格的约定等等. 对程序效率影响最大的往往是数据结构和算法的选择, 而不是具体的编码细节, 例如用 if(p) 而不是 if(p == NULL), 等等 ...
我也很同意你的说法。 还有说可以少打几个字的朋友，代码只打一次，但是你的代码却可能被人阅读N次。
|
