r = 127;

int sum = 200;

chr += 1; // 127为chr的边界值，再加1将使chr上溢到-128，而不是128。

sum += chr; // 故sum的结果不是328，而是72。

若chr与sum为同一种类型，或表达式按如下方式书写，可能会好些。

sum = sum + chr + 1;

.9-8：留心程序机器码大小（如指令空间大小、数据空间大小、堆栈空间大小等）是否超出系

统有关限制。

.9-9：为用户提供良好的接口界面，使用户能较充分地了解系统内部运行状态及有关系统出错

情况。

.9-10：系统应具有一定的容错能力，对一些错误事件（如用户误操作等）能进行自动补救。

.9-11：对一些具有危险性的操作代码（如写硬盘、删数据等）要仔细考虑，防止对数据、硬

件等的安全构成危害，以提高系统的安全性。

.9-12：使用第三方提供的软件开发工具包或控件时，要注意以下几点：

（1）充分了解应用接口、使用环境及使用时注意事项。

（2）不能过分相信其正确性。

（3）除非必要，不要使用不熟悉的第三方工具包与控件。

说明：使用工具包与控件，可加快程序开发速度，节省时间，但使用之前一定对它有较充

分的了解，同时第三方工具包与控件也有可能存在问题。

.9-13：资源文件（多语言版本支持），如果资源是对语言敏感的，应让该资源与源代码文件

脱离，具体方法有下面几种：使用单独的资源文件、dll文件或其它单独的描述文件（如数据

库格式）

10 代码编辑、编译、审查

110-1：打开编译器的所有告警开关对程序进行编译。

110-2：在产品软件（项目组）中，要统一编译开关选项。

110-3：通过代码走读及审查方式对代码进行检查。

说明：代码走读主要是对程序的编程风格如注释、命名等以及编程时易出错的内容进行检

查，可由开发人员自己或开发人员交叉的方式进行；代码审查主要是对程序实现的功能及

程序的稳定性、安全性、可靠性等进行检查及评审，可通过自审、交叉审核或指定部门抽

查等方式进行。

110-4：测试部测试产品之前，应对代码进行抽查及评审。

.10-1：编写代码时要注意随时保存，并定期备份，防止由于断电、硬盘损坏等原因造成代码

丢失。

.10-2：同产品软件（项目组）内，最好使用相同的编辑器，并使用相同的设置选项。

说明：同一项目组最好采用相同的智能语言编辑器，如muiti editor，visual editor

等，并设计、使用一套缩进宏及注释宏等，将缩进等问题交由编辑器处理。

.10-3：要小心地使用编辑器提供的块拷贝功能编程。

说明：当某段代码与另一段代码的处理功能相似时，许多开发人员都用编辑器提供的块拷

贝功能来完成这段代码的编写。由于程序功能相近，故所使用的变量、采用的表达式等在

功能及命名上可能都很相近，所以使用块拷贝时要注意，除了修改相应的程序外，一定要

把使用的每个变量仔细查看一遍，以改成正确的。不应指望编译器能查出所有这种错误，

比如当使用的是全局变量时，就有可能使某种错误隐藏下来。

.10-4：合理地设计软件系统目录，方便开发人员使用。

说明：方便、合理的软件系统目录，可提高工作效率。目录构造的原则是方便有关源程序

的存储、查询、编译、链接等工作，同时目录中还应具有工作目录----所有的编译、链

接等工作应在此目录中进行，工具目录----有关文件编辑器、文件查找等工具可存放在

此目录中。

.10-5：某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手段去掉告

警信息。

说明：在borland c/c++中，可用“#pragma warn”来关掉或打开某些告警。

示例：

#pragma warn -rvl // 关闭告警

int examples_fun( void )

{

// 程序，但无return语句。

}

#pragma warn +rvl // 打开告警

编译函数examples_fun时本应产生“函数应有返回值”告警，但由于关掉了此告警信

息显示，所以编译时将不会产生此告警提示。

.10-6：使用代码检查工具（如c语言用pc-lint）对源程序检查。

.10-7：使用软件工具（如 logiscope）进行代码审查。

11 代码测试、维护

111-1：单元测试要求至少达到语句覆盖。

111-2：单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。

111-3：清理、整理或优化后的代码要经过审查及测试。

111-4：代码版本升级要经过严格测试。

111-5：使用工具软件对代码版本进行维护。

111-6：正式版本上软件的任何修改都应有详细的文档记录。

.11-1：发现错误立即修改，并且要记录下来。

.11-2：关键的代码在汇编级跟踪。

.11-3：仔细设计并分析测试用例，使测试用例覆盖尽可能多的情况，以提高测试用例的效率。

.11-4：尽可能模拟出程序的各种出错情况，对出错处理代码进行充分的测试。

.11-5：仔细测试代码处理数据、变量的边界情况。

.11-6：保留测试信息，以便分析、总结经验及进行更充分的测试。

.11-7：不应通过“试”来解决问题，应寻找问题的根本原因。

.11-8：对自动消失的错误进行分析，搞清楚错误是如何消失的。

.11-9：修改错误不仅要治表，更要治本。

.11-10：测试时应设法使很少发生的事件经常发生。

.11-11：明确模块或函数处理哪些事件，并使它们经常发生。

.11-12： 坚持在编码阶段就对代码进行彻底的单元测试，不要等以后的测试工作来发现问题。

.11-13：去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内

部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现。

12 宏

112-1：用宏定义表达式时，要使用完备的括号。

示例：如下定义的宏都存在一定的风险。

#define rectangle_area( a, b ) a * b

#define rectangle_area( a, b ) (a * b)

#define rectangle_area( a, b ) (a) * (b)

正确的定义应为：

#define rectangle_area( a, b ) ((a) * (b))

112-2:将宏所定义的多条表达式放在大括号中。

示例：下面的语句只有宏的第一条表达式被执行。为了说明问题，for语句的书写稍

不符规范。

#define inti_rect_value( a, b )\

a = 0;\

b = 0;

for (index = 0; index < rect_total_num; index++)

inti_rect_value( rect.a, rect.b );

正确的用法应为：

#define inti_rect_value( a, b )\

{\

a = 0;\

b = 0;\

}

for (index = 0; index < rect_total_num; index++)

{

inti_rect_value( rect[index].a, rect[index].b );

}

112-3:使用宏时，不允许参数发生变化。

示例：如下用法可能导致错误。

#define square( a ) ((a) * (a))

int a = 5;

int b;

b = square( a++ ); // 结果：a = 7，即执行了两次增1。

正确的用法是：

b = square( a );

a++; // 结果：a = 6，即只执行了一次增1。

_

---------------------------用户上传之内容结束--------------------------------

声明：本书为txt图书下载网(bookshuku.com)的用户上传至其在本站的存储空间，本站只提供txt全集电子书存储服务以及免费下载服务，以上作品内容之版权与本站无任何关系。