同人星球BBS -> 基础编程 -> [转帖]程序的书写规范 [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

djgcn 06-11-08 13:08

转自：http://genial.yculblog.com/post.1071658.html

　　随着软件产品的功能增加和版本的提高，代码越来越复杂，源文件也越来越多，对于软件开发人员来说，除了保证程序运行的正确性和提高代码的运行效率之外，规范风格的编码会对软件的升级、修改、维护带来极大的方便性，也保证程序员不会陷入“代码泥潭”中无法自拔。开发一个成熟的软件产品，除了有详细丰富的开发文档之外，必须在编写代码的时候就有条不紊，细致严谨。

　　以下的编码规范包含了程序排版、注释、命名、可读性、变量、程序效率、质量保证、代码编译、代码测试和版本控制等注意事项。

　　一、排版：
　　1.关键词和操作符之间加适当的空格。
　　2.相对独立的程序块与块之间加空行。
　　3.较长的语句、表达式等要分成多行书写。
　　4.划分出的新行要进行适应的缩进，使排版整齐，语句可读。
　　5.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
　　6.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
　　7.若函数或过程中的参数较长，则要进行适当的划分。
　　8.不允许把多个短语句写在一行中，即一行只写一条语句。
　　9.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
　　10.C/C++语言是用大括号‘{’和‘}’界定一段程序块的，编写程序块时‘{’和‘}’应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。

　　二、注释
　　1.注释要简单明了。
　　2.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
　　3.在必要的地方注释，注释量要适中。注释的内容要清楚、明了，含义准确，防止注释二义性。保持注释与其描述的代码相邻，即注释的就近原则。
　　4.对代码的注释应放在其上方相邻位置，不可放在下面。
　　5.对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；同一结构中不同域的注释要对齐。
　　6.变量、常量的注释应放在其上方相邻位置或右方。
　　7.全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
　　8.在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。
　　9.在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等。

　　三、命名
　　1.较短的单词可通过去掉“元音”形成缩写；
　　2.较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
　　3.使用匈牙利表示法

　　四、可读性
　　1.避免使用不易理解的数字，用有意义的标识来替代。
　　2.不要使用难懂的技巧性很高的语句。
　　3.源程序中关系较为紧密的代码应尽可能相邻。

　　五、变量
　　1.去掉没必要的公共变量。
　　2.构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
　　3.仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
　　4.明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
　　5.当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
　　6.防止局部变量与公共变量同名。
　　7.仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减少引起误用现象。
　　8.结构的设计要尽量考虑向前兼容和以后的版本升级，并为某些未来可能的应用保留余地（如预留一些空间等）。
　　9.留心具体语言及编译器处理不同数据类型的原则及有关细节。
　　10.严禁使用未经初始化的变量。声明变量的同时对变量进行初始化。
　　11.编程时，要注意数据类型的强制转换。

　　六、函数、过程
　　1.函数的规模尽量限制在200行以内。
　　2.一个函数最好仅完成一件功能。
　　3.为简单功能编写函数。
　　4.函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
　　5.尽量不要编写依赖于其他函数内部实现的函数。
　　6.避免设计多参数函数，不使用的参数从接口中去掉。
　　7.用注释详细说明每个参数的作用、取值范围及参数间的关系。
　　8.检查函数所有参数输入的有效性。
　　9.检查函数所有非参数输入的有效性，如数据文件、公共变量等。
　　10.函数名应准确描述函数的功能。
　　11.避免使用无意义或含义不清的动词为函数命名
　　12.函数的返回值要清楚、明了，让使用者不容易忽视错误情况。
　　13.明确函数功能，精确（而不是近似）地实现函数设计。
　　14.减少函数本身或函数间的递归调用。
　　15.编写可重入函数时，若使用全局变量，则应通过关中断、信号量（即P、V操作）等手段对其加以保护。

　　七、可测性
　　1.在编写代码之前，应预先设计好程序调试与测试的方法和手段，并设计好各种调测开关及相应测试代码如打印函数等。
　　2.在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细分析并优化测试用例，以提高测试效率。

　　八、程序效率
　　1.编程时要经常注意代码的效率。
　　2.在保证软件系统的正确性、稳定性、可读性及可测性的前提下，提高代码效率。
　　3.不能一味地追求代码效率，而对软件的正确性、稳定性、可读性及可测性造成影响。
　　4.编程时，要随时留心代码效率；优化代码时，要考虑周全。
　　5.要仔细地构造或直接用汇编编写调用频繁或性能要求极高的函数。
　　6.通过对系统数据结构划分与组织的改进，以及对程序算法的优化来提高空间效率。
　　7.在多重循环中，应将最忙的循环放在最内层。
　　8.尽量减少循环嵌套层次。
　　9.避免循环体内含判断语句，应将循环语句置于判断语句的代码块之中。
　　10.尽量用乘法或其它方法代替除法，特别是浮点运算中的除法。

　　九、质量保证
　　1.在软件设计过程中构筑软件质量。代码质量保证优先原则
　　（1）正确性，指程序要实现设计要求的功能。
　　（2）稳定性、安全性，指程序稳定、可靠、安全。
　　（3）可测试性，指程序要具有良好的可测试性。
　　（4）规范/可读性，指程序书写风格、命名规则等要符合规范。
　　（5）全局效率，指软件系统的整体效率。
　　（6）局部效率，指某个模块/子模块/函数的本身效率。
　　（7）个人表达方式/个人方便性，指个人编程习惯。
　　2.只引用属于自己的存贮空间。
　　3.防止引用已经释放的内存空间。
　　4.过程/函数中分配的内存，在过程/函数退出之前要释放。
　　5.过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函数退出前要关闭。
　　6.防止内存操作越界。
　　7.时刻注意表达式是否会上溢、下溢。
　　8.认真处理程序所能遇到的各种出错情况。
　　9.系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。
　　10.系统运行之初，要对加载到系统中的数据进行一致性检查。
　　11.严禁随意更改其它模块或系统的有关设置和配置。
　　12.不能随意改变与其它模块的接口。
　　13.充分了解系统的接口之后，再使用系统提供的功能。
　　14.要时刻注意易混淆的操作符。当编完程序后，应从头至尾检查一遍这些操作符。
　　15.不使用与硬件或操作系统关系很大的语句，而使用建议的标准语句。
　　16.建议：使用第三方提供的软件开发工具包或控件时，要注意以下几点：
　　（1）充分了解应用接口、使用环境及使用时注意事项。
　　（2）不能过分相信其正确性。
　　（3）除非必要，不要使用不熟悉的第三方工具包与控件。

　　十、代码编译
　　1.编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码丢失。
　　2.同一项目组内，最好使用相同的编辑器，并使用相同的设置选项。
　　3.合理地设计软件系统目录，方便开发人员使用。
　　4.打开编译器的所有告警开关对程序进行编译。
　　5.在同一项目组或产品组中，要统一编译开关选项。
　　6.使用工具软件（如Visual SourceSafe）对代码版本进行维护。

　　十一、代码测试、维护
　　1.单元测试要求至少达到语句覆盖。
　　2.单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
　　3.清理、整理或优化后的代码要经过审查及测试。
　　4.代码版本升级要经过严格测试。

整理者：中子

littlewater 06-11-08 19:51
虽然说很有用，但是毕竟和程序的直接实现关系不甚，加上现在个人比较流行 独来独往，因此容易导致更加觉得没有必要了……

个人意见还是多写写，比如和YUKI，AVC等那样，自然而然就能够体会到这些东西，加上通过自身理解然后再去看，就能够真正看到有用的东西了～

yuki 06-11-10 10:48
随便说说：反正每一个人的喜好不一样。自己写的时候顺其自然就可以。小程序可以不注意。大一点的程序就要统一风格了。不过如果和别人做项目的话，就要先商量好统一的风格
一、排版：
要善用tab键。一个层次的代码缩进一样。
二、注释
一般写代码的时候都尽量写自注释代码。就是不要注释也可以看懂的代码。注释一般是加在类或函数的前面。一般正规的类方法注释有：说明功能，前置条件，后置条件，不变式，返回值，in / out 参数，异常抛出等。这是按契约编程的习惯。实际中只用说明功能。返回值和参数就可以了。
三、命名
推荐C++ 和 Java 程序员用java的风格。C程序员用unix风格。个人不喜欢匈牙利
四、可读性
只要命名好了，代码一般比较好读。但注意尽量不要使用技巧，真的要用技巧的代码（例如速度要求很快的代码）应该加注释：注释上写上此代码的功能，及其简单版本（同一功能但是速度慢的）。
六、函数、过程
和OO中的类一样。函数尽量高内聚，如果一个函数完成了太多功能，建议重构Extract Method
七、可测性
写一个模块就要测试。写一个小程序。使用模块的功能核对输出。C++没有Junit的方便。
但是如果有自动化的测试工具还是用一下好。我自己没有用过自动化的测试工具。
八、程序效率
不同意：“1.编程时要经常注意代码的效率。” 一般是编程时使代码尽量简单可读，在实际测试阶段如果发现代码效率低。再进行优化不迟。上面说的优化代码必须加注释。注释上就可以写原来易读的代码，有一句话，只作你真正需要的。不作你认为需要的。程序的80％时间花在20％的关键代码上。只要关键代码优化好了。程序会非常快。如果一开始就注意优化，既花费精力又用力不到位。而且使整体代码维护困难。

下面懒的说了。。。反正多看看商业质量的源码，学习他们的编程方法一定不会错的。

littlewater 06-11-11 18:54
不错，都归纳了八点了^^

advance 06-11-19 14:32
个人的一些习惯：

统一的：
符号命名类似M$ DDK（既不同于K&R也不同于匈牙利的一种规范）
非全局生存的变量用小写命名，并缩写超出6个英文字母的单词

有分歧的：

高级语言：
缩进：不使用缩进符，取而代之的是4个空格。大括号单独一行，多项判断和多参数调用均分行书写。
OO：我不会使用模版元和泛型编程，所以仅注意部件功能上的封装和分离，以及足够的概念抽象空间。遵循单入单出的思想，不通过异常机制传递自定义异常，严格检查参数及执行状况并在出错时返回足够多的错误信息。核心思想遵循KISS，可伸缩性摆在第一位，运行效率不在考虑范围之内。
注释：基本上只有函数（方法）功能描述和参数部分会有注释（因为我特别懒）。
PO：尽量以简单的方式书写代码，首要目的是减少工作量，同样不考虑运行效率。

低级语言：
通常是体积第一，效率第二，首次书写代码即予以最高级别的优化（觉得难调试的多半是熟练度不够，多读一下其它编译器的反汇编代码就好），珍惜每一个CPU时钟周期和每一个字节的空间。短跳转标签不赋予特定意义的名称，每行指令前使用一个缩进。不书写任何注释，也不使用类似高级语言语句的伪宏。


查看完整版本: [-- [转帖]程序的书写规范 --] [-- top --]

Powered by PHPWind v5.3 Code © 2003-05 PHPWind
Time 0.085809 second(s),query:4 Gzip enabled

You can contact us