有争议的代码风格
Eric.Wang
2，"NULL =="和"== NULL"，何者是更好的代码风格？
我提出这两个问题，是源于理论和实践的脱节。
++i在很多情况下可以有更好的性能。"NULL =="可以避免“==”被误写为“=”。
从理论上来看，这似乎应该是更好的代码。反对的理由不太站得住脚：习惯、顺眼。
但是我看了一些优秀的开源项目代码，发现大多数都是写成“i++”和"== NULL"的。
当理论和实践出现脱节的时候，你们会选择相信理论，还是跟从实践？
Eric.Wang
http://www.lighttpd.net/download/lighttpd-1.4.22.tar.gz
里面的代码我摘录几段：
array.c:
for (j = a->used; j < a->size; j++) a->data[j] = NULL;
mod_scgi.c:
for (i = 0; i < f->used; i++) {
server.c:
for (i = 0; i < FILE_CACHE_MAX; i++) {
request.c
for (; *c && *c != ']'; c++) {
Daniel Lv
SevenCat
符合逻辑习惯。
变量和常量的运算中，一般可能是变量在前面。如果是乘的话2*a和a*2可能差不多符合逻辑习惯。
这个比较有意思，我翻了C#：
msdn中C#的例子:
// statements_for.cs
// for loop
using System;
public class ForLoopTest
{
public static void Main()
{
for (int i = 1; i <= 5; i++)
Console.WriteLine(i);
}
}
SevenCat
iterator++和++iterator在for里面的汇编代码是完全一样的。
On 5月3日, 下午11时05分, "Eric.Wang" <wangshaoq...@gmail.com> wrote:
Jay True
我不是说从这种地方看不出来，不过我觉得设计才更能体现吧？
以上。
--
歌词唱清楚，不是周杰伦
Home Page: http://glacjay.is-a-geek.org/blog/
Eric.Wang
设计确实更能体现好的品味，清爽的设计和纠结的设计更能体现程序员的品味。不过设计的好坏更难评估，好的设计通常也是平平无奇的，你通常只能从结果来判
断，这个设计是好的。当你看到一个平平无奇的设计的时候，你很难凭空判断这个设计是好的还是坏的，一个设计的好坏，通常是和具体应用环境相关的。在这里
是个好设计，在那里可能就是个坏设计。
从代码的细处，也是能看出程序员的价值取向和品味的。能否把代码写得清晰简洁美观，除了基本功，还需要程序员的品味。比如，喜欢写“++i”或
者“NULL ==”的家伙，品味相对来说可能就差了点，因为他们仅仅根据不可靠的网上文章（比如林锐那篇编程指南）或者不完整的理论，就写出了让自己
也让别人别扭的代码。
设计确实更能体现程序员的品味，但是编码更直观更更容易检验。
wing
==，虽然看比起来别扭，但是除非做了更好的替代，比如用工具检查,否则==写成=，并不是一件好玩的事情，特别在比较大的项目中，程序员水平又参差不齐时。
某设备大厂商，一个生产系统当了数小时，找了很久才找出的原因，居然就是一个判断中==写成了=，这种事并不是什么天荒夜谈，在没有更好的方式前，null
== 还是有意义的，除非你用更好的方式代替它，例如编译器的设置，或者工具检查，否则这点代价还是要付出的。
2009/5/4 Eric.Wang <wangsh...@gmail.com>:
--
wing
wing9...@gmail.com
Hope is a good thing, maybe the best of things.
Eric.Wang
g++比较差一些，不能提供这个提示。于是我们用C#写了一个小工具，专门检查if ()括号里面有没有赋值操作。我们公司的策略是if ()里面尽量
不要做赋值操作（有些旧的代码在if里面赋值了，我们的工具可以标记这些代码，并略过检查）。
把==写成=，其实是逻辑错误。程序的逻辑错误有很多，这主要是需要通过测试来保证正确。测试做得不完整，怎么写代码都是没用的。
On 5月4日, 上午9时35分, wing <wing922w...@gmail.com> wrote:
> 也不完全是这样的，比如说null
> ==，虽然看比起来别扭，但是除非做了更好的替代，比如用工具检查,否则==写成=，并不是一件好玩的事情，特别在比较大的项目中，程序员水平又参差不齐时。
>
> 某设备大厂商，一个生产系统当了数小时，找了很久才找出的原因，居然就是一个判断中==写成了=，这种事并不是什么天荒夜谈，在没有更好的方式前，null
> == 还是有意义的，除非你用更好的方式代替它，例如编译器的设置，或者工具检查，否则这点代价还是要付出的。
>
> 2009/5/4 Eric.Wang <wangshaoq...@gmail.com>:
>
>
>
>
>
> > 设计确实更能体现好的品味，清爽的设计和纠结的设计更能体现程序员的品味。不过设计的好坏更难评估，好的设计通常也是平平无奇的，你通常只能从结果来判
> > 断，这个设计是好的。当你看到一个平平无奇的设计的时候，你很难凭空判断这个设计是好的还是坏的，一个设计的好坏，通常是和具体应用环境相关的。在这里
> > 是个好设计，在那里可能就是个坏设计。
>
> > 从代码的细处，也是能看出程序员的价值取向和品味的。能否把代码写得清晰简洁美观，除了基本功，还需要程序员的品味。比如，喜欢写"++i"或
> > 者"NULL =="的家伙，品味相对来说可能就差了点，因为他们仅仅根据不可靠的网上文章（比如林锐那篇编程指南）或者不完整的理论，就写出了让自己
> > 也让别人别扭的代码。
>
> > 设计确实更能体现程序员的品味，但是编码更直观更更容易检验。
>
> > On 5月4日, 上午8时28分, Jay True <glac...@gmail.com> wrote:
> >> 好的品味难道非得从这种地方才能看出来的么？
>
> >> 我不是说从这种地方看不出来，不过我觉得设计才更能体现吧？
>
> >> 以上。
>
> >> --
> >> 歌词唱清楚，不是周杰伦
> >> Home Page:http://glacjay.is-a-geek.org/blog/
>
> --
> wing
wang feng
> 1，"++i"和"i++"，何者是更好的代码风格？
> 2，"NULL =="和"== NULL"，何者是更好的代码风格？
>
> 我提出这两个问题，是源于理论和实践的脱节。
>
> ++i在很多情况下可以有更好的性能。"NULL =="可以避免“==”被误写为“=”。
> 从理论上来看，这似乎应该是更好的代码。反对的理由不太站得住脚：习惯、顺眼。
>
> 但是我看了一些优秀的开源项目代码，发现大多数都是写成“i++”和"== NULL"的。
>
pwd && cat *.c |grep 'for ('
/home/feng/src/glibc-2.9-20090427/rt
for (cnt = 0; cnt < nent; ++cnt)
for (cnt = 0; cnt < 10; ++cnt)
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 0; cnt < 1000; ++cnt)
for (cnt = 0; cnt < 10; ++cnt)
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (i = 0; i < BYTES; i++)
for (cnt = 0; cnt < nent; ++cnt)
for (cnt = 0; cnt < 10; ++cnt)
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 0; cnt < 1000; ++cnt)
for (cnt = 0; cnt < 10; ++cnt)
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (cnt = 10; cnt > 0; )
for (i = 0; i < 10; ++i)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 100; ++i)
for (size_t j = 0; j < sizeof buf; ++j)
for (int i = 0; i < 10; ++i)
for (int i = 0; i < 10; ++i)
for (int i = 1; i < argc; ++i)
for (long l = TF_MQ_RECEIVE; l <= TF_MQ_TIMEDSEND; ++l)
for (i = 0; i <= 4; ++i)
for (i = 0; i <= 4; ++i)
for (i = 0; i <= 4; ++i)
for (i = 0; i <= 4; ++i)
for (i = 0; i < 100; i++)
for (i = 0; i < 100; i++)
> 当理论和实践出现脱节的时候，你们会选择相信理论，还是跟从实践？
>
wang feng
> 1，"++i"和"i++"，何者是更好的代码风格？
> 2，"NULL =="和"== NULL"，何者是更好的代码风格？
>
> 我提出这两个问题，是源于理论和实践的脱节。
>
> ++i在很多情况下可以有更好的性能。"NULL =="可以避免“==”被误写为“=”。
> 从理论上来看，这似乎应该是更好的代码。反对的理由不太站得住脚：习惯、顺眼。
>
> 但是我看了一些优秀的开源项目代码，发现大多数都是写成“i++”和"== NULL"的。
>
>
> 当理论和实践出现脱节的时候，你们会选择相信理论，还是跟从实践？
>
Jockey S. Kyd
所以最好还是养成条件反射，外加lint辅助。
2009/5/4 wing <wing9...@gmail.com>:
Tiny fool
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Phone: 13520711089
Twitter:http://twitter.com/tinyfool
银杏泰克科技有限公司-专业的站内搜索引擎提供商
http://www.ginkgotek.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
Eric.Wang
MFC 1789 12
Libxml2 47 4
Lighttpd 213 129
Apache 1070 5
Coreutils 420 0
Gaim 1044 0
Firefox 7781 2166
Open Office 2583 398
Emule 550 47
Linux kernel 12436 318
glibc 3715 0
On 5月4日, 上午9时35分, wing <wing922w...@gmail.com> wrote:
> 也不完全是这样的，比如说null
> ==，虽然看比起来别扭，但是除非做了更好的替代，比如用工具检查,否则==写成=，并不是一件好玩的事情，特别在比较大的项目中，程序员水平又参差不齐时。
>
> 某设备大厂商，一个生产系统当了数小时，找了很久才找出的原因，居然就是一个判断中==写成了=，这种事并不是什么天荒夜谈，在没有更好的方式前，null
> == 还是有意义的，除非你用更好的方式代替它，例如编译器的设置，或者工具检查，否则这点代价还是要付出的。
>
> 2009/5/4 Eric.Wang <wangshaoq...@gmail.com>:
>
>
>
>
>
> > 设计确实更能体现好的品味，清爽的设计和纠结的设计更能体现程序员的品味。不过设计的好坏更难评估，好的设计通常也是平平无奇的，你通常只能从结果来判
> > 断，这个设计是好的。当你看到一个平平无奇的设计的时候，你很难凭空判断这个设计是好的还是坏的，一个设计的好坏，通常是和具体应用环境相关的。在这里
> > 是个好设计，在那里可能就是个坏设计。
>
> > 从代码的细处，也是能看出程序员的价值取向和品味的。能否把代码写得清晰简洁美观，除了基本功，还需要程序员的品味。比如，喜欢写"++i"或
> > 者"NULL =="的家伙，品味相对来说可能就差了点，因为他们仅仅根据不可靠的网上文章（比如林锐那篇编程指南）或者不完整的理论，就写出了让自己
> > 也让别人别扭的代码。
>
> > 设计确实更能体现程序员的品味，但是编码更直观更更容易检验。
>
> > On 5月4日, 上午8时28分, Jay True <glac...@gmail.com> wrote:
> >> 好的品味难道非得从这种地方才能看出来的么？
>
> >> 我不是说从这种地方看不出来，不过我觉得设计才更能体现吧？
>
> >> 以上。
>
> >> --
> >> 歌词唱清楚，不是周杰伦
> >> Home Page:http://glacjay.is-a-geek.org/blog/
>
> --
> wing
Li Feng
至于性能，嗯，i++和++i我感觉都是可以忽略的东西。
一般你参加到一个项目中去，更不必要去考虑这些东西了，有代码
都写好了，照着写就是了。
Li Feng
2009/5/3 Eric.Wang <wangsh...@gmail.com>:
Eric.Wang
恩，我统计了glibc里面，i++有484次，++i有1057次。我看了一下使用的场合，发现里面i++大多是用在crypt、strcpy、
memcpy这样极端需要性能的地方。在极端需要性能的时候，品味是要让位于需求的。
即使是在glibc这样极端考虑移植和优化的地方，i++仍然出现了484次，我认为这仍然说明i++是更好的品味。甚至可以说，写代码的人是尽量在使
用i++的，只是出于性能考虑，不得不使用++i。
我回头查一下我前面的赌注，看我算不算输。。。。输了的话我就单独发帖说明我输了。。。。只要group里面的人不觉得我发新topic是骚
扰。。。。
补充说明一下：
在firefox里面是6623次和2195次。
在linux kernel里面是20894次和2098次。
在MFC里面是448次和36次。
都是i++远远多于++i。
> string.list.tar.bz2
> 2K查看下载
Jeffrey Zhao
1、“极端需要性能”的地方大都使用“i++”
2、“i++”品位高，性能差（相对）
为什么得出“在极端需要性能的时候，品味是要让位于需求的”？
Jeffrey Zhao
Blog: http://jeffreyzhao.cnblogs.com
Twitter: http://twitter.com/jeffz_cn
--------------------------------------------------
From: "Eric.Wang" <wangsh...@gmail.com>
Sent: Monday, May 04, 2009 10:47 AM
To: "TopLanguage" <pon...@googlegroups.com>
Subject: [TL] Re: 有争议的代码风格
Eric.Wang
1、对不起，这个地方是我写错了，笔误，应该是"极端需要性能"的地方大都使用"++i" 。
2、i++ 和++i能否在优化之后得到同样的性能，可能会取决于软硬件平台(包括编译器）。glibc需要在尽可能多的平台上获得尽可能好的性能，因
此他们写代码的时候写++i是可以理解的。而且glic的历史非常悠久（以IT行业来说），当时的一些写法可能有当时的一些考虑。
品味实际上任何时候都是要让位于需求的。当需求是性能的时候，品味就要让位于性能。
On 5月4日, 上午10时51分, "Jeffrey Zhao" <je...@live.com> wrote:
> 我有点没看懂：
>
> 1、"极端需要性能"的地方大都使用"i++"
> 2、"i++"品位高，性能差（相对）
>
> 为什么得出"在极端需要性能的时候，品味是要让位于需求的"？
>
> Jeffrey Zhao
> Blog:http://jeffreyzhao.cnblogs.com
> Twitter:http://twitter.com/jeffz_cn
>
> --------------------------------------------------
> From: "Eric.Wang" <wangshaoq...@gmail.com>
Mea Culpa
个人希望我国软件行业有一个大量规范化的
代码编写群体早就的强健的产业基础，
而不是只有讲究品位的艺术家创造的空中花园
我们不是北欧
--
=================
Holier Than Thou!
=================
Eric.Wang
对于代码工人，确实只要遵循规范就可以了。更高的要求是，不止要有规范，而且还要有好的规范。好的规范才容易被认可，容易被执行。
殷远超
殷远超
halida
程序員應該關注在設計上面，而不是考慮語法和結構。
C太自由了（或者說那個時候設計語言時沒有考慮到這樣的問題？）
William Xu
C++ 里面 i 如果是对象，比如 stl iterator, 那开销还是不小的。
反正 ++i, i++ 从视觉效果来看，并没有太大的差别。++i 既然有时效率更好，那
我觉得养成 ++i 的习惯挺好的（尤其在循环体内）…
--
William
DarkRaven
孙辉
孙辉
Aw Guo
1，"++i"和"i++"，何者是更好的代码风格？
2，"NULL =="和"== NULL"，何者是更好的代码风格？
我提出这两个问题，是源于理论和实践的脱节。
++i在很多情况下可以有更好的性能。"NULL =="可以避免“==”被误写为“=”。
从理论上来看，这似乎应该是更好的代码。反对的理由不太站得住脚：习惯、顺眼。
但是我看了一些优秀的开源项目代码，发现大多数都是写成“i++”和"== NULL"的。
当理论和实践出现脱节的时候，你们会选择相信理论，还是跟从实践？
Daniel Lv
chaoyan ma
大家仍然关系到底在编译器以及语言特性上，++i和i++有什么不同阿....唉～～如果测试用例都通过了，运行结果也没有问题，那么就团队举手表决吧，如果大家都习惯其中一种写法，就用那种，反之亦然，最重要的是++i或i++都是写给人看的。
--
最初的梦想
Eric.Wang
我承认你说的有一定道理，++i和i++仅仅是阅读上顺畅与否的问题，不会带来理解上的困难，也不会带来强烈的不适应。但是为什么实践上大多数成功的开
源项目都是写成i++而不写++i呢？微软的MFC也大多写i++。
在firefox里面是6623次和2195次。
在linux kernel里面是20894次和2098次。（差不多是最著名最成功的开源项目了吧，里面i++的数量差不多是++i的数量的十倍）
在MFC里面是448次和36次。（这是最成功的软件公司提供的的最重要的基础开发架构）
都是i++远远多于++i。
目前仅有的一个反例glibc也仅仅是484次和1057次，仍然有484次i++。
为什么不用i++，我的观点就是代码阅读起来越顺畅约好。即使“不会带来理解上的困难和强烈的不适应”，只要有阅读一些不顺畅，写代码就要尽量写成阅读
顺畅的方式。这在理论上缺乏说服力，但是实践说明这是一种好的方式。我们应该跟随理论，还是实践呢？
On 5月5日, 上午9时58分, chaoyan ma <chaoyan...@gmail.com> wrote:
> 这个就不太同意了 ++i 和i++ 在人看来没什么太大区别（不会带来理解上的困难和强烈的不适应）
> 但是对编译器来说 ++i比 i++效率更高 做的工作更少 那么为什么不用++i 呢~
>
> 2009/5/5 Daniel Lv <lgn2...@gmail.com>
chaoyan ma
--
最初的梦想
Eric.Wang
修订一下：为什么不用++i，我的观点就是代码阅读起来越顺畅越好。即使“不会带来理解上的困难和强烈的不适应”，只要阅读有一些不顺畅，写代码就要尽
量写成阅读
顺畅的方式。这在理论上缺乏说服力，但是实践说明这是一种好的方式。我们应该跟随理论，还是实践呢？
另外再说一下"== NULL"还是"NULL =="的问题：
Linux kernel 12436 318
glibc 3715 0
在linux kernel里面，"NULL =="只出现了318次，而glibc里面“NULL ==”根本就一次都没有。
这也是理论和实践出现了冲突。
我的观点是：理论上说得再好听也没用。实践是检验真理的唯一标准。代码的可读性是非常重要的，没有十分必要的理由，代码就应该写得符合常人的逻辑和阅读
习惯。
chaoyan ma
另外 人家优秀也不是因为把 NULL== 写成==NULL 但是 我们写==NULL 也不一定优秀 反而可能耗费更多时间 写NULL==也不阻挡你优秀
--
最初的梦想
Eric.Wang
于"避免==写成="之上。
如果"对已知确定事物 统计不能作为证据"，那什么叫做"归纳法"？
把优秀项目里面共同的特质提取出来，为什么就不能成为好的经验呢？仅仅因为一些不充分的理论吗？
On 5月5日, 上午10时45分, chaoyan ma <chaoyan...@gmail.com> wrote:
> ......
> 统计...... 对已知确定事物 统计不能作为证据
> 就比如 ++i 已知效率比i++高 就请不要用统计这个表面上的数据来作为论据
> 就比如我吧，在此之前可能关注过++i 比i++ 效率高 但是写代码的时候也习惯性用i++
> 但是 现在意识到这是一个不好的习惯 然后 开始注意纠正 那不是很好吗？
>
> "优秀只是一种习惯" 不知道哪里的名言了
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
Eric.Wang
Linux kernel 12436 318
glibc 3715 0
在linux kernel里面，"NULL =="只出现了318次，而glibc里面"NULL =="根本就一次都没有。
我知道"NULL =="的写法可以避免一部分==写成=的错误，但是和"可读性"比起来，不值得。
如果不是"可读性"的原因，我不知道如何解释"在linux kernel里面，"NULL =="只出现了318次，而glibc里面"NULL
=="根本就一次都没有"。
On 5月5日, 上午10时58分, chaoyan ma <chaoyan...@gmail.com> wrote:
> 代码习惯不是一种理论的东西
> 首先 理论上的话 ==NULL 和NULL== 效果一样
> 但是 NULL== 这样的写法能避免出现更多的bug（防止少写一个=）
>
> 另外 人家优秀也不是因为把 NULL== 写成==NULL 但是 我们写==NULL 也不一定优秀 反而可能耗费更多时间
> 写NULL==也不阻挡你优秀
> 最后 请问 ==NULL 和NULL==阻碍了您的可读性吗？
>
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
居振梁
--
自学走了不少弯路，更浪费了太多的时间，寻找良师益友。
追求黑客精神和清心寡欲的心态。
http://wargrey.yo2.cn
http://wargrey.blogspot.com
主要兴趣：Unix/GNU Linux、人工智能、移动计算、虚拟化
其他兴趣：心理学、自然科学、数学、武术、自然语言
qiaojie
wangmao
Eric.Wang
你的意思是所有这些优秀的项目，都不约而同的使用了“不好的代码风格”，而且还都恰好成为了优秀的项目，是吗？
我认为这不是偶然。这是优秀项目共有的特质：注重可读性甚于理论。
On 5月5日, 上午11时07分, 居振梁 <juzhenli...@gmail.com> wrote:
> 这个问题真没必要争了，这跟“为什么IT行业内部的人里还是用windows多”是一个道理
>
> --
> 自学走了不少弯路，更浪费了太多的时间，寻找良师益友。
> 追求黑客精神和清心寡欲的心态。http://wargrey.yo2.cnhttp://wargrey.blogspot.com
Jeffrey Zhao
wangmao
Eric.Wang
我"，在逻辑上都是完整的，只要大家习惯宾语和主语的位置。
那么，你会因为"QWERT"不如"ABCDE"的排列整齐，就要求全公司都改习惯，让他们用"ABCDE"的键盘吗？
"++i"和"NULL =="涉及的就是脑子里面的思维的习惯，思维的习惯是几十年和人谈话交流形成的。要改可以，但不是无代价的。值得吗？
On 5月5日, 上午11时09分, qiaojie <qiao...@gmail.com> wrote:
> 习惯跟自然顺畅关系不大的，完全是先入为主的。比方说，中国古代的书写顺序是从上往下从右往左，跟洋人的完全相反，你能说是哪个更自然顺畅吗？还有QWERT键盘，这种排列方式是因为某个商人故意搞出来噱头，其实没什么科学根据的，但是就成了大家的习惯，以致按字母排列的键盘反而没人能用的惯了。你能说QWERT排列比ABCDE排列更自然顺畅吗？
>
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
qiaojie
把== null改成null == 确实能带来一定好处，但是编程大师们可能认为这些好处不足以成为改变自己习惯
的理由，因为他们是大师，不可能犯这种低级的错误。如果你一定要什么都跟大师学，反而可能会犯郑
人学步、东施效颦的错误，所以大可不必在这个上面如此执着。
Eric.Wang
何谓意义？
对程序员来说，代码风格就是标准。制定标准怎么能说是无意义的呢？很多公司都规定使用”NULL ==“，我认为这是谬种流传，伤害了中国的程序员。
On 5月5日, 上午11时14分, wangmao <lwm3...@gmail.com> wrote:
> 如果人并非只有黄种人一样，好的代码风格也并非只有一种。你心目中的好风格，并不妨碍别人心目中的好风格，把自己的喜好强加在别人身上这不是什么好习惯。然后，我宣布不再对此话题进行发言，没意义。
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
qiaojie
Eric.Wang
"如果你一定要什么都跟大师学，反而可能会犯郑人学步、东施效颦的错误"，这是meaningless的说辞，可以放在任何地方，因为借鉴任何东西
都”可能会犯郑人学步、东施效颦的错误“。
”把== null改成null == 确实能带来一定好处“，这是对的，但是并不是免费的。因此是一个需要取舍的问题，而不是非此不可的问题。很多人
只看到了这样做的好处，没有看到在可读性上付出的代价，因为”可读性“是难以量化的。
这些优秀的项目都做了取舍，而且不约而同的选择了可读性。我认为这些优秀项目中共同的部分，是值得借鉴的。
On 5月5日, 上午11时19分, qiaojie <qiao...@gmail.com> wrote:
> 我觉得这位老兄大可不必一定要找出这些习惯背后的内在逻辑，很多习惯其实是没有什么道理可言的。
> 把== null改成null == 确实能带来一定好处，但是编程大师们可能认为这些好处不足以成为改变自己习惯
> 的理由，因为他们是大师，不可能犯这种低级的错误。如果你一定要什么都跟大师学，反而可能会犯郑
> 人学步、东施效颦的错误，所以大可不必在这个上面如此执着。
>
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
chaoyan ma
--
最初的梦想
chaoyan ma
最初的梦想
qiaojie
Ian Young, Yingcai
对于++i，在Google公开的C++ Style有一条，分析了优缺点：
Preincrement and Predecrement
▽ Use prefix form (++i) of the increment and
decrement operators with iterators and other template objects.
Definition:
When a variable is incremented (++i or
i++) or decremented (--i or
i--) and the value of the expression is not used,
one must decide whether to preincrement (decrement) or
postincrement (decrement).
Pros:
When the return value is ignored, the "pre" form
(++i) is never less efficient than the "post"
form (i++), and is often more efficient. This is
because post-increment (or decrement) requires a copy of
i to be made, which is the value of the
expression. If i is an iterator or other
non-scalar type, copying i could be expensive.
Since the two types of increment behave the same when the
value is ignored, why not just always pre-increment?
优点：++i性能更好，特别对于非内置类型
Cons:
The tradition developed, in C, of using post-increment when
the expression value is not used, especially in for
loops. Some find post-increment easier to read, since the
"subject" (i) precedes the "verb" (++),
just like in English.
缺点：i++写法在C中是种传统，而且主语在谓词前面更容易读
Decision: For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment.
Sincerely, Ian Yang
Sent from Shanghai, 31, China
Eric.Wang
实际上这还是一个“理论重要”，还是“可读性重要”的问题。“理论”很具有迷惑性，在国内带坏了一批人。实际上优秀的项目都返璞归真，注重代码的可读性
甚于理论。
你的提醒很对。因为这里是没有利益纠葛的group，所以我才可以这么无所顾忌的发表观点呀。多多包涵，呵呵
On 5月5日, 上午11时41分, qiaojie <qiao...@gmail.com> wrote:
> 呵呵，你可以保留你的意见。我只是觉得你在这种习惯问题上如此执着，可能会在团队合作上出现一些障碍，个体去改变群体的习惯是非常困难的，在这种习惯问题上争论不休只会造成团队无谓的内耗。只是善意的提醒，如有冒犯请海涵。
>
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
pongba
我相信大家都想从这个小例子泛化到一般情况，讨论一个较大的“编码风格和习惯”的问题，但泛化论点的时候需要注意这个泛化是否成立，比如对于NULL==还是==NULL的可读性问题，到底有多严重呢。
值得注意的是NULL==的可读性和一般情况下奇怪写法的可读性并不是同一个概念，一个是特例，一个是一般情况，不可简单类比的。是的，可读性 是一个非常重要的衡量标准，是的，很多时候奇怪的写法的确带来不可忽视的可读性成本，但这个一般性原则是否适用NULL==这个特例呢？还是那句话，it depends.
另外，我们在决策的时候容易陷入一个“最优化陷阱”，哪怕差别是如此的细微，也仿佛一定要比较出一个高下出来，难道不能就简单的接受这样一个论点：“两者都无所谓，差别是非显著的，与其为止费神半天，付出很大的时间成本，还不如省省力去做点别的呢” :)
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
chaoyan ma
Fei Yan
这个东西压根儿就没有好多人想象的那么重要，如果想讨论其他一些东西，举出合适的例子再展开似乎更妥当些
“群众的眼睛是雪亮的”和“真理往往掌握在少数人手里”往往会冲突
Eric.Wang
正面的例子已经有了，那就是这么多的优秀项目都是写“i++”和“NULL ==”的。反面的例子不好找，因为反面的例子都湮灭了。。。。
On 5月5日, 上午11时56分, chaoyan ma <chaoyan...@gmail.com> wrote:
> ~~~ 不如这样吧 大家习惯不一样的不妨各自组队 然后看看效果如何
>
> 2009/5/5 Eric.Wang <wangshaoq...@gmail.com>
Eric.Wang
泡惯了bbs，帖子是可以编辑的。老是要修订自己的笔误，不好意思。
Eric.Wang
是我为什么认为这个问题值得讨论。
如果这个问题能够拓展到更广泛的范围，那很好；如果不能拓展，那么这两个问题本身也因为其广泛性而值得讨论。
有些公司会在代码规范里面强制要求写++i和NULL == p的格式，我认为这不但不近人情，而且通过损害可读性而损害了代码的质量。（我们公司没有
这两条见鬼的规定，但我知道有些公司是有的）。
可读性是难以量化的，因此在讨论的时候常常缺乏说服力。但是事实是有说服力的，这是我为什么去统计优秀项目做法的原因。
PS：为了减少笔误，我现在先在word里面写完了文章，又阅读了三遍才贴上来。希望能减少笔误。。。。。
Ian Young, Yingcai
++i 212行
i++ 2行，都用在ptrdiff_t上
2） 觉得记 “ 如果可能，尽量使用 ++i " 比 "使用i++, 当效率比可读性重要时使用++i" 容易。一是一致性，二是什么时候效率>可读性不好把握。
huangchao
--------------------------------------------test.c
int main()
{
int i;
++i;
return 0;
}
--------------------------------------------test2.c
int main()
{
int i;
i++;
return 0;
}
#gcc -S test.c
#gcc -S test2.c
得出的汇编代码其实是一样的
-------------------------------------------testx.s
.file "testx.c"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $16, %esp
addl $1, -8(%ebp)
movl $0, %eax
addl $16, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3"
.section .note.GNU-stack,"",@progbits
我猜现在的编译器估计已经很强大了，保持好的习惯当然更好
On May 3, 11:05 pm, "Eric.Wang" <wangshaoq...@gmail.com> wrote:
> 1，"++i"和"i++"，何者是更好的代码风格？
> 2，"NULL =="和"== NULL"，何者是更好的代码风格？
>
> 我提出这两个问题，是源于理论和实践的脱节。
>
> ++i在很多情况下可以有更好的性能。"NULL =="可以避免"=="被误写为"="。
> 从理论上来看，这似乎应该是更好的代码。反对的理由不太站得住脚：习惯、顺眼。
>
> 但是我看了一些优秀的开源项目代码，发现大多数都是写成"i++"和"== NULL"的。
>
> 当理论和实践出现脱节的时候，你们会选择相信理论，还是跟从实践？
Korben Zhang
编译最快，最接近机器语言，DSL最慢，但开发效率更高，一句顶十句。
2009/5/5 Eric.Wang <wangsh...@gmail.com>:
> ++i/i++和NULL == p/p == NULL的写法确实很细微，但是这个问题的影响面却很广泛，几乎所有C++程序员都会面临这个选择。这
> 是我为什么认为这个问题值得讨论。
> 如果这个问题能够拓展到更广泛的范围，那很好；如果不能拓展，那么这两个问题本身也因为其广泛性而值得讨论。
--
Korben Zhang
http://sites.google.com/site/korbenzhang/
Jason
Ian Young, Yingcai
struct XX {
XX& operator++() {
++p_;
return *this;
}
XX operator++(int) {
XX tmp = *this;
++p_;
return tmp;
}
private:
YY p_;
}
i++需要临时对象保存++之前的状态
Sincerely, Ian Yang
胡翟
sagittarius.boy
XiongJia Le
const_iterator& operator++()
{ // preincrement
_Ptr = _Nextnode(_Ptr);
return (*this);
}
const_iterator operator++(int)
{ // postincrement
const_iterator _Tmp = *this;
++*this;
return (_Tmp);
}
chaoyan ma
正面的例子已经有了，那就是这么多的优秀项目都是写“i++”和“NULL ==”的。反面的例子不好找，因为反面的例子都湮灭了。。。。
--
最初的梦想
chaoyan ma
不过本来 机器的学习方式 就是模仿人的……
居振梁
chaoyan ma
CoreWar
On 5月5日, 下午7时37分, chaoyan ma <chaoyan...@gmail.com> wrote:
> 哦~ 我知道了 您的意思是 在未知i++ 和++i的方式下进行的统计 没有得到对应的解是吧？
> 呵呵 我觉得 这个 可能还要考虑更多的因素在里面 比如 使用++i的作者的权威
> 其相关++i了解的程度（比如他是搞过编译器或者知道汇编）这个时候需要给这个部分的统计加上（乘于）相应的权重
>
> i++ 和++i 这样比较明确的例子只是判断正误的问题
> 而关于 其它没有答案 只有习惯的问题 那么统计的时候 对不同的集合 应该相应的再拓展相连的因素
> 比如 还是上面的例子吧 统计出i++ 和++i 的两个集合 然后 再这两个集合的基础上 再统计代码的出处 作者 作者职位 ...... 等等 你感兴趣的因素
chaoyan ma
OxFAN
legendsland
居振梁
（特指）在程序员中自诩为艺术家，假设这是成立的。不是更适合解决风格问题吗？
通常此类人都是比较牛的，不会只纠缠于一门语言，至少同时精通并使用多门语言的概率要远远大于其他人，这么一来接触不同风格（相对他的第一门语言）语言便几乎是必然的。在众多语言（风格）里切换，想必就是艺术家应达到的基本层次（也许在别人看来是很高的境界）吧？
对上述“精通”的定义：对于特定的语言，掌握所有语法和语言特性，能写出符合该语言思想的程序，并且熟悉所有关于此语言的规范、约定等一些列非硬性规定的条目。
PS：这里不包括能很好的解决语言所面向的领域的问题的能力，因为这是一个无底洞，没有极限，难以量化。
风格只是针对艺术家而言的。但是（在中国的）程序员真的可以自诩为艺术家吗？
DaiZW
因为"NULL =="不符合逻辑习惯,
所以每次遇到需要写"NULL =="或者"== NULL"的时候思维都会停一下, 然后决定用"NULL =="来代替"== NULL",
那么, 有这个思维停顿的时间, 为什么不用它来检查一下是"=="还是"="呢?
chaoyan ma
up duan
以lighttpd的代码为例子
http://www.lighttpd.net/download/lighttpd-1.4.22.tar.gz
里面的代码我摘录几段：
array.c:
for (j = a->used; j < a->size; j++) a->data[j] = NULL;
mod_scgi.c:
for (i = 0; i < f->used; i++) {
server.c:
for (i = 0; i < FILE_CACHE_MAX; i++) {
request.c
for (; *c && *c != ']'; c++) {
chaoyan ma
--
最初的梦想
Roof
只想说，对我而言，如果项目不严加要求，那么我会写NULL==，因为我宁愿有些人读起来别扭一点，
也要扼杀我不小心写出（p=NULL）这种状况的可能性，理由是，我就曾经犯过这种错。
如果有人读起来觉得别扭，那很抱歉，我很乐意请他喝杯咖啡贿赂贿赂。看多了自然不会别扭了。
至于为什么那么多优秀项目用i++多过++i，我想，肯定有其理由，但仅仅具有参考价值。这里面是质
量原因还是历史原因，有待考察。就我而言，已经习惯了写++i，我实在找不出有什么理由一定要换回
来。
两个论点：
1、理论上正确的，不一定在实践中吃香。
2、大多数优秀项目采取的做法不一定是一定要跟从的做法，虽然肯定有它们的理由。
对于p==NULL还是NULL==p，我觉得有个衡量标准，就是，如果你会犯if ( p = NULL )这种错误，或者
你的代码里，有“正确的”if ( p = NULL )这样的语句，你的本意就是赋值，那么还是乖乖的写“理论正确”
的写法吧，不然恐怕大伙对你没信心。如果你从不犯错，那谁怪罪你呢。
不要强求，这没什么大的讨论价值，窃以为。
aleung
我不负责任的估计，99%的应用的性能都不会因为使用++i或i++带来什么影响。
如果是这样，拘泥于这样的性能又有什么意义？
On May 5, 9:58 am, chaoyan ma <chaoyan...@gmail.com> wrote:
> 这个就不太同意了 ++i 和i++ 在人看来没什么太大区别（不会带来理解上的困难和强烈的不适应）
> 但是对编译器来说 ++i比 i++效率更高 做的工作更少 那么为什么不用++i 呢~
>
wizard
++i比i++的效率更高，这是没有任何疑问的事情
如果i是整型，那或许这种效率差别并不很大，但是如果i是迭代器，那么在某些需要大量循环的例子中，++i和i++在性能上的区别很可能是决定性的。
2009/5/4 Eric.Wang <wangsh...@gmail.com>:
>
> 设计确实更能体现好的品味，清爽的设计和纠结的设计更能体现程序员的品味。不过设计的好坏更难评估，好的设计通常也是平平无奇的，你通常只能从结果来判
> 断，这个设计是好的。当你看到一个平平无奇的设计的时候，你很难凭空判断这个设计是好的还是坏的，一个设计的好坏，通常是和具体应用环境相关的。在这里
> 是个好设计，在那里可能就是个坏设计。
>
> 从代码的细处，也是能看出程序员的价值取向和品味的。能否把代码写得清晰简洁美观，除了基本功，还需要程序员的品味。比如，喜欢写“++i”或
> 者“NULL ==”的家伙，品味相对来说可能就差了点，因为他们仅仅根据不可靠的网上文章（比如林锐那篇编程指南）或者不完整的理论，就写出了让自己
> 也让别人别扭的代码。
>
> 设计确实更能体现程序员的品味，但是编码更直观更更容易检验。
>
>
> On 5月4日, 上午8时28分, Jay True <glac...@gmail.com> wrote:
>> 好的品味难道非得从这种地方才能看出来的么？
>>
>> 我不是说从这种地方看不出来，不过我觉得设计才更能体现吧？
>>
>> 以上。
>>
>> --
>> 歌词唱清楚，不是周杰伦
>> Home Page:http://glacjay.is-a-geek.org/blog/
翁翊成
OxFAN
即使++i比i++效率要高，但对应用的整体性能影响有多大呢？很明显，你不了解为什么++i比i++效率高。前面的帖子已经说的比较清楚了。
我不负责任的估计，99%的应用的性能都不会因为使用++i或i++带来什么影响。
chaoyan ma
chaoyan ma
qiaojie
Totally Wrong!即使++i比i++效率要高，但对应用的整体性能影响有多大呢？很明显，你不了解为什么++i比i++效率高。前面的帖子已经说的比较清楚了。而且照这么说，很多的性能优化对整体性能的影响都可以被忽略。对尾递归的优化可以被忽略，函数定义为内联可以被忽略，使用对象引用而不是对象本身做参数可以被忽略.....我不负责任的估计，99%的应用的性能都不会因为使用++i或i++带来什么影响。这样的估计的确不负责任。正是这些细小的优化最终使真个程序或模块的性能得到提高，从而增强了用户的体验，对这些细节不重视的人写不出高质量的代码，也做出不优秀的软件。程序性能也是整个软件是否对人友好的一个重要参考。
没有数据的证明，性能优化就会成为瞎掰。
写成i++虽然会多产生一个临时变量，但是你怎么知道编译器就不会把这个无用的临时变量优化掉呢？既然编译器有RVO优化，这种无用的临时变量赋值被内联展开以后编译器一样可以判断出是无用代码，可以被去除掉。就算有些编译器不做这个优化，但是多一次临时变量会影响多少效率呢？没有测试数据的话真是的没法估计。据我个人经验，对一般非平凡的循环体多一次临时变量赋值其影响不可能超过1%，谁要是有空的话，可以写个测试用例。
qiaojie
其实 ++i 跟 i+=1，i=i+1 是一样道理的，当编译器把代码内联展开以后，可以做很多优化工作的，这三种写法最终得到的代码是一样的。
说了半天还是建议大家不必太执着于这些无聊的小地方，不要教条化，多把时间用于有意义的方面吧。
Jeffrey Zhao
Jiaxin Huang
所以
第一，真个项目，整个公司必须统一使用同一种 coding style, ++i 或者 i++
第二，如果公司不 care 性能方面的问题，或者公司对所谓的品位有执着的追求，那就全用 i++， 没问题
如果公司认为虽然只有 5% 的地方会有性能上的问题，但为了全公司统一，全部用 ++i， 没问题
对于职业的IT民工来说，我相信不用一个星期就能从一种 style 转换到另外一种 style.
2009/5/6 Jeffrey Zhao <je...@live.com>:
--
--
To be a betterman.
Jeffrey Zhao
除此之外我还真想不到类似的问题。
Jeffrey Zhao
Blog: http://jeffreyzhao.cnblogs.com
Twitter: http://twitter.com/jeffz_cn
--------------------------------------------------
From: "Jiaxin Huang" <better...@gmail.com>
Sent: Wednesday, May 06, 2009 10:33 PM
qiaojie
OxFAN
- i+=1，i=i+1 的行为也不一样，一样的道理，同样无需我在这里证明。
- 至于“编译器的优化”，这是个非常笼统的概念，不具一般性和代表性，它跟编译器的实现、版本、优化等级，是否开优化等等等等有关。如果非要说明有这样的优化，也应该具体到那个编译器的哪个版本和哪个编译参数。
qiaojie
int test(vector<int>& v)
{
int total = 0;
for(vector<int>::iterator it = v.begin(); it != v.end(); it++)
total += *it;
return total;
}
下面是这段代码我用VS2008 release版编译出来的结果。为了看起来简单一些我把
_SECURE_SCL关闭了，这样可以减少很多check代码，影响大家的视线。
PUBLIC ?test@@YAHAAV?$vector@HV?$allocator@H@std@@@std@@@Z ; test
; Function compile flags: /Ogtpy
; File c:\documents and settings\qiaojie\desktop\test\test\test.cpp
; COMDAT ?test@@YAHAAV?$vector@HV?$allocator@H@std@@@std@@@Z
_TEXT SEGMENT
_v$ = 8 ; size = 4
?test@@YAHAAV?$vector@HV?$allocator@H@std@@@std@@@Z PROC ; test, COMDAT
; 10 : int total = 0;
; 11 : for(vector<int>::iterator it = v.begin(); it != v.end(); it++)
mov edx, DWORD PTR _v$[esp-4]
mov ecx, DWORD PTR [edx+4]
mov edx, DWORD PTR [edx+8]
xor eax, eax
cmp ecx, edx
je SHORT $LN1@test
$LL16@test:
; 12 : total += *it;
add eax, DWORD PTR [ecx]
add ecx, 4
cmp ecx, edx
jne SHORT $LL16@test
$LN1@test:
; 13 :
; 14 : return total;
; 15 : }
请注意看循环体的代码：
$LL16@test:
; 12 : total += *it;
add eax, DWORD PTR [ecx]
add ecx, 4
cmp ecx, edx
jne SHORT $LL16@test
没有临时变量没有变量赋值，说明编译器完全可以实现这个优化。
2009/5/6 OxFAN <oday...@gmail.com>
up duan
一般在我主导的项目开发中，我不会强制规定代码规范。程序员是需要保持一定的个性的，你把他们当代码民工，强制规定一些规范，遇到一些个性强的人会产生抵触情绪，不可能很好的发挥每个人的创造力。其实很多风格方面的东西只是一些习惯不同而已，不存在什么原则性的问题，有时候我自己也会在代码中尝试几种不同的风格或者玩玩奇巧淫技，编程是件有趣的事情，不要搞的太死板。不过，代码的格式化我会要求统一，这个可以有工具自动完成，如果格式不统一的话merge会有大麻烦，这个是没有办法的。
aleung
设计阶段 - 设计是否有性能隐患？例如不必要的远程调用，不合适的数据库查询方式。特别是涉及架构上的问题，做出来后是很难再调优的。
测试阶段 - 做性能测试，看看是否已经达到预定的性能要求。如果没有达到需求，通过各种工具分析性能瓶颈在哪里，找出关键影响因素进行调优。
我同意程序性能也是整个软件是否对人友好的一个重要参考，但怎样才算是性能足够好？必须要有个衡量的指标，性能的调优可以是无穷无尽的，但实际上并不需
要榨干每一毫秒。如果处理用户的一次请求只需要500ms，那么你把它优化成450ms也不会带来什么用户体验的提升。
确实，在我做过的软件中，基本上都不用怎么关注尾递归、函数内联、对象引用的问题，因为它们并没有成为性能瓶颈。我会选择一种让代码容易理解、维护的方
式来做。如果真的发现某处代码由于没有考虑这些因素成为了性能瓶颈，通过重构来修改也是轻而易举的事情。
On May 6, 1:49 pm, OxFAN <odayf...@gmail.com> wrote:
> Totally Wrong!
>
> > 即使++i比i++效率要高，但对应用的整体性能影响有多大呢？
>
> 很明显，你不了解为什么++i比i++效率高。前面的帖子已经说的比较清楚了。
> 而且照这么说，很多的性能优化对整体性能的影响都可以被忽略。
> 对尾递归的优化可以被忽略，函数定义为内联可以被忽略，使用对象引用而不是对象本身做参数可以被忽略.....
>
> > 我不负责任的估计，99%的应用的性能都不会因为使用++i或i++带来什么影响。
>
> 这样的估计的确不负责任。
>
> 正是这些细小的优化最终使真个程序或模块的性能得到提高，从而增强了用户的体验，对这些细节不重视的人写不出高质量的代码，也做出不优秀的软件。
> 程序性能也是整个软件是否对人友好的一个重要参考。
> 2009/5/6 aleung <leoli...@gmail.com>