Chrome源码印象

 

      在n年的等待后（n>5)我终于找到了一款非常喜欢用的，C++的OpenSource项目。但是，一看到2g的源文件和编译所需的10g硬盘空间，我只好abandon了。这是一年多以前的事。

      前几天又想起来了，以先browse不compile的决心用TortoiseSVN check out，虽然我对在VC中按F5键有非同寻常的偏好。经过几个小时的check（中间TortoiseSVN n次因为connection error而stop），终于done了。整个文件夹包括png文件之类的杂七杂八的东西，2g左右。然后发现找不到vc2008能打开的sln或者vcproj文件，于是开始用Google狂搜，发现有人提到要用Google自己开发的一个叫gclient的工具来下载。这时才想起在chromium的guide上看到过这玩意儿，但是觉得没TortoiseSVN方便，就直接忽略了。没办法，下了这玩意儿接着check，还好能接着TortoiseSVN check。n小时之后发现磁盘空间不足，仔细权衡，痛苦思考之后，删了一些暂时不玩的游戏和X片。到check完毕，一共占用4g多一点的空间，用了两个白天，睡觉时关机了。

      经过上述的曲折经历后，终于在vc2008熟悉的界面中看到了Chrome的source code。因为网上已有一篇精到的源码剖析：

http://www.cnblogs.com/duguguiyu/archive/2008/10/02/1303095.html

      在我找出有价值的新东西前，不打算写详细的分析，只说些关于代码风格的印象。

 

      作为当今软件工业最高水平的代表之一，同时又是OpenSource project，Chrome的source code在任意一个方面都必须达到顶级水准，不然肯定会被口水淹死。虽然做到了这点，也只能保证口水不淹到腰部以上。

      首先注意到的是代码的宽度，下面是个例子：

      各个文件并没有严格统一宽度，大约是略小于80列。正好是1024×768分辨率，vc2005/2008四面的tabs全部固定之后，code editor的宽度。因为宽度并不是严格统一，个人推断并不是用代码美化的工具自动生成，而是人工设置。而且工具生成的话，也不能准确的断好comments的行。这种设置兼顾了还没有使用宽屏的阅读者，毕竟需要左右拖动滑动条才能完整阅读code会浪费很多时间。

      然后就是这详细到罗嗦的comments。关于comments，programmers中会有很多争议。按个人的体会，这种东西，写的人很痛苦，不管写的好还是差。而对于看的人，如果是good comments，那可以省很多事，如果很bad，就有可能引发disaster。我粗略的估计了一下，comment的字数应该超过了有效code的字数。用如此高密度的comments，个人猜想，应该还是由于代码量太大，为了让人能尽快理解和上手。毕竟programmers‘ brain的容量是非常小的。一般来说，即使自己写的code，半年之后完全不看comments，还能记得自己为什么要这么写，几率都是很小的。何况要maintain大量别人写的code。不过如此大量的comments，能保证绝大部分能准确描述思路，这对programmers的要求很高。当然，Google的developers达到这个要求应该是很正常的。

      下面有两个地方比较有意思：

        

      这里极其有耐心的给出example usage，虽然example错拼成了exampe，但是对于经常忘吃饭，忘睡觉，经常对着一堆code抓狂的programmer来说，我觉得是可以理解的。在我有限的code阅读中，在comment中给出example，只有ms这么干过，MFC中很多。一般来说，大部分programmers，包括我自己，都没有这个意识去想自己写下的class或者function，到底应该怎么用比较好。如果不当使用，会出现什么后果。往往是觉得，这么用test能通过，就这么用了，然后就赶紧去做下面的item了。也许这种意识是工人与设计师的一个显著区别。

 

      还有这里，这位brother，也可能是sister，估计是给乱改的抓狂了，直接把Effective C++上的出处给列了出来。这样简单明了，会认字的去看看，就不会继续干傻事了。但在中国，可能这么做就行不通了。结果往往是，有人跑来问Effective C++是什么？告知之后，回复：我们做个维护而已/做个小项目而已/时间很紧/运行效率要求不高，有必要看这么高级的书吗？这还算好的，更糟的是，这条comment直接被忽略，code继续被乱改。我不知道在国内，有多少用C++的人真正看过这本Effective C++，反正我曾经的同事好像还没有看过的，包括一位有八年经验的先生。很多人看完那本谭浩强的把C++当C用的书，再找几本VC的速成，就以为自己懂了，然后心安理得的在C++的IDE中写C代码。于是天量的垃圾代码就在滥用中诞生了。其实很多事，第一步做对了，可以少很多麻烦。就像夏季外出远足，中途突然乌云密布，自己却因为嫌累而没带雨伞，那种感觉应该不大好。

 

      另外就是些比较抽象的东西。整体而言，这是个重量级的project，源文件数量接近一万。用现在的主流配置，compile需要2小时以上。但是分类比较合理，通过project name就可以很容易找到相关的source file。个人认为，上面说过的那篇源码剖析中提到的多线程的实现方式最有学习价值，不过要彻底明白，就要去啃那本硬得像牛骨头一样的《Modern C++ Design》，真是件痛苦的事。