在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责,缺省是由函数调用者负责。
函数的规模尽量限制在200行以内。说明:不包括注释和空格行。
一个函数仅完成一件功能。函数的功能应该是可以预测的,也就是只要输入数据相同就应产生同样的输出。
检查函数所有参数输入的有效性。检查函数所有非参数输入的有效性,如数据文件、公共变量等。
说明:函数的输入主要有两种:一种是参数输入;另一种是全局变量、数据文件的输入,即非参数输入。函数在使用输入之前,应进行必要的检查。
函数名应准确描述函数的功能。
6-30:当一个过程(函数)中对较长变量(一般是结构的成员)有较多引用时,可以用一个意义相当的宏代替。
说明:这样可以增加编程效率和程序的可读性。
示例:在某过程中较多引用 TheReceiveBuffer[FirstSocket].byDataPtr,
则可以通过以下宏定义来代替:
# define pSOCKDATA TheReceiveBuffer[FirstScoket].byDataPtr
用宏定义表达式时,要使用完备的括号。 #define RECTANGLE_AREA( a, b ) ((a) * (b))
将宏所定义的多条表达式放在大括号中。
用调测开关来切换软件的DEBUG版和正式版,而不要同时存在正式版本和DEBUG版本的不同源文件,以减少维护的难度。 软件的DEBUG版本和发行版本应该统一维护,不允许分家,并且要时刻注意保证两个版本在实现功能上的一致性。 在编写代码之前,应预先设计好程序调试与测试的方法和手段,并设计好各种调测开关及相应测试代码如打印函数等。 在保证软件系统的正确性、稳定性、可读性及可测性的前提下,提高代码效率。通过对系统数据结构的划分与组织的改进,以及对程序算法的优化来提高空间效率。 说明:这种方式是解决软件空间效率的根本办法。 对模块中函数的划分及组织方式进行分析、优化,改进模块中函数的组织结构,提高程序效率。 说明:软件系统的效率主要与算法、处理任务方式、系统功能及函数结构有很大关系 代码质量保证优先原则 (1)正确性,指程序要实现设计要求的功能。 (2)稳定性、安全性,指程序稳定、可靠、安全。 (3)可测试性,指程序要具有良好的可测试性。 (4)规范/可读性,指程序书写风格、命名规则等要符合规范。 (5)全局效率,指软件系统的整体效率。 (6)局部效率,指某个模块/子模块/函数的本身效率。 (7)个人表达方式/个人方便性,指个人编程习惯。
只引用属于自己的存贮空间。说明:若模块封装的较好,那么一般不会发生非法引用他人的空间。
防止引用已经释放的内存空间。
过程/函数中分配的内存,在过程/函数退出之前要释放。
过程/函数中申请的(为打开文件而使用的)文件句柄,在过程/函数退出之前要关闭。
防止内存操作越界。说明:内存操作主要是指对数组、指针、内存地址等的操作。
严禁随意更改其它模块或系统的有关设置和配置。说明:编程时,不能随心所欲地更改不属于自己模块的有关设置如常量、数组的大小等。
不能随意改变与其它模块的接口。
Unix下,多线程的中的子线程退出必需采用主动退出方式,即子线程应return出口。
不要滥用goto语句。说明:goto 语句会破坏程序的结构性,所以除非确实需要,最好不使用 goto 语句。
不使用与硬件或操作系统关系很大的语句,而使用建议的标准语句,以提高软件的可移植性和可重用性。
精心地构造、划分子模块,并按“接口”部分及“内核”部分合理地组织子模块,以提高“内核”部分的可移植性和可重用性。
时刻注意表达式是否会上溢、下溢。使用变量时要注意其边界值的情况。
为用户提供良好的接口界面,使用户能较充分地了解系统内部运行状态及有关系统出错情况。
系统应具有一定的容错能力,对一些错误事件(如用户误操作等)能进行自动补救。
:使用第三方提供的软件开发工具包或控件时,要注意以下几点:
(1)充分了解应用接口、使用环境及使用时注意事项。
(2)不能过分相信其正确性。
(3)除非必要,不要使用不熟悉的第三方工具包与控件。
编写代码时要注意随时保存,并定期备份,防止由于断电、硬盘损坏等原因造成代码丢失。
同产品软件(项目组)内,最好使用相同的编辑器,并使用相同的设置选项。
1⁄210-6:使用代码检查工具(如C语言用PC-Lint)对源程序检查。
1⁄210-7:使用软件工具(如 LogiSCOPE)进行代码审查。
单元测试开始要跟踪每一条语句,并观察数据流及变量的变化。
11-3:清理、整理或优化后的代码要经过审查及测试。
11-4:代码版本升级要经过严格测试。
11-5:使用工具软件对代码版本进行维护。
11-6:正式版本上软件的任何修改都应有详细的文档记录。
1⁄211-1:发现错误立即修改,并且要记录下来。
仔细设计并分析测试用例,使测试用例覆盖尽可能多的情况,以提高测试用例的效率。
1⁄211-4:尽可能模拟出程序的各种出错情况,对出错处理代码进行充分的测试。
1⁄211-5:仔细测试代码处理数据、变量的边界情况。
坚持在编码阶段就对代码进行彻底的单元测试,不要等以后的测试工作来发现问题。
A、数据类型特别是int相关的类型在不同位数机器的平台下长度不同。
B、为了保证平台的通用性，程序中尽量不要使用long数据类型。可以使用固定大小的数据类型宏定义。
typedef unsigned char int8_t;
请勿假设int和指针的长度相同。
请勿假设int和long的长度相同。
可以只使用一种系统来开发多个平台的程序。例如，使用GCC，你可在一个64位的AMD64平台上，同时生成32位x86应用程序和64位AMD64应用程序，生成32位程序时，只需要在编译器中带上“-m32。
23、在Unix系统上，ILP32（整型int、长整型long、指针pointer）数据模型对64位应用程序不再适用。如果你之前在写程序时，已假定所有的int、long、指针的长度都是32比特，那么现在必须要掉转头来重写一遍，因为此时long和指针的长度已是64比特(LP64)。特定要提醒的是，要仔细检查一切有关int、long、指针的赋值和比较语句。
24、在64位Windows系统上，long的长度依然是32比特，但指针和long long是64位，这被称作LLP64模型。
26、要在常量表达式中指定数据类型。如果你想使一个常量为long，必须清楚地在数值后跟上l或者L，否则，编译器有可能把它当作int来对待。
28、小心C语言中的符号扩展问题。举例来说，当转换一个unsigned int到64位的unsigned long时，它必须先转换成一个signed int，然后是signed long，最后才能转换成unsigned long。在此期间，任何数值超过2的31次方的int值，将会被系统当成一个负数，而负号也会扩展到因转换成long而新增的32个比特位中，最后被转换成的unsigned long数值，将会比原值大许多。