写别人看得懂的C/C++代码

   首先必须澄清一个误解，就是代码写的越难懂，写代码的程序员就越厉害。事实不是这样的，恰好相反，代码写的难懂，说明这个程序员的编码质量越差。

代码的质量，不仅仅包括在满足功能需求的前提下，代码是否高效是否稳定， 还应包别人是否很容易就能理解。在一个企业中，代码写出来迟早是要给别人看的。既然别人要看你写的代码，那么自然免不了要理解它。相信大家都有这种感觉，就是一段代码，如果没看明白，很难在原有代码上去修改它的功能。正因为如此，大家都不愿意去接手一份很难看明白的代码。看懂代码有多重要，写看得懂的代码就有多重要。

这里就C/C++代码的可读性谈一点自己的体会。

   按照难度逐渐加大的次序，理解一份代码的方式排列方式如下：

ü         看目录/文件/类/函数/变量名称(容易)

ü         静态阅读函数详细代码(较困难)

ü         正常执行代码(困难)

ü         动态调试代码(非常困难)

ü         单步调试代码(非常困难)

可以看出来，仅仅通过目录/文件/类/函数/变量名称就让人理解代码的功能，是最理想的增强可读性的方式。实在不行，通过静态阅读函数详细代码就能理解，也是可以接受的。如果要通过动态调试代码才能理解，可读性已经不怎么样了。如果要单步调试才能理解，那么基本上是不可维护的。维护这样的代码，与其花大量时间去单步调试，还不如重新实现一个更好的。

物理文件布局

  一个项目包含100个.cpp文件，如果都存放在一个目录里，会显得比较零乱。这时可以按照模块分别存放在不同的子目录里，从而显得比较清晰。不同模块的代码放入不同的目录，让别人在看某个文件的代码之前，心里就能有一个大概的方向，从而更快的理解代码。在一个多人项目里，这样做也便于使用版本控制工具进行权限管理。对于一个包含大量文件的工程项目，设计出良好的目录结构是确保代码可读性的第一个有效措施。

命名原则

  命名包括文件命名和类、变量、函数等的命名。这里谈几个最重要的命名原则。

ü         名称与功能相适应

如果说眼睛是心灵的窗户，那么名称就是功能的窗户。最理想的命名是看了文件名，就不用看文件的内容；看了函数名，就不用看函数的实现。

ü         英文还是拼音

  尽量使用英文，毕竟在程序设计世界里英文才是真正的通用语言。当然，如果发现业务所在领域的专业英语非常复杂，又是针对中国客户时，使用拼音也不失为一个好办法。最忌讳在同一个文件中，甚至同一个函数中混杂英文和拼音两种命名方式。

ü         名称长度适中

  尽管现在的编译器对于符号长度的限制越来越小了，但是还是要选择一个长度适中的名称。名称太长，一眼看不过来，影响阅读。名称太短，又很难精确表达功能含义。一般在4到12个字母比较合适。

ü         循环计数器

如果循环体的代码很多，循环计数器又参与到循环体的代码中，尤其是有多重循环，那么最好为婚环计数器选用一个有意义的名称，否则，使用象i,j,k之类的名称显得更简洁。

 总而言之，让人一眼就能看明白而且不用看注释不用查文档的名称，就是好名称。

保持单纯

保持单纯就是保持功能的单一。文件、类、函数以及变量，都是如此。一个文件，尽量只做一件事情，如果必要，也可以扩大到只做一类功能相关的事情。一个类，只实现一组密切相关的功能。一个函数，那就真的只能做一件事情了。一个变量，只表示一个属性或者状态。

状态无关的变量

变量的含义特别忌讳与系统状态有关。一个变量的含义，在程序员声明它的时候已经唯一确定了，系统状态的改变，只能改变变量的值，而不能改变变量固有的含义。如果随着系统的运行，同一个变量刚才代表物体的数量，现在又代表物体的质量，那就让人难以理解。

慎用struct-type-union-struct

常见的struct-type-union-struct就是类似下面的定义：

Struct  Geometry {

GeometryType   objType;

Union GeometryInternal {

     Struct  Point    pt;

   Struct  Polyline  line;

   Struct  Polygon  area;

}
 };

Struct Geometry  geo;

Geo是一个Point，Polyline还是Polygong, 由objType的值决定.。这似乎没有问题，但是，程序员必须保证objType和pt/line/area的一致性。这给别人的理解造成了困难。因为这意味着在静态分析代码的情况下，别人很难明白geo到底是什么，pt , line, 还是area?

一些经典的类型定义在这方面起到了误导程序员的副作用。比如VC里的VARIANT结构体就是这样。

作者信息

Email     robotom@sina.com

MSN      robotom@sina.com

BLOG    http://blog.csdn.net/robotom/

发表于 @ 2007年03月30日 19:41:00|评论(loading...)|编辑