软件Bug是怎样写成的.docVIP

软件Bug是怎样写成的 1 头文件 规则 1.1 头文件中仅放置接口的声明，不放置接口的实现； 例如内部使用的宏、枚举、结构定义不应放在头文件中，变量定义不应放在头文件中，而应当放在.c文件中；如果使用全局变量，也应当在.c中定义全局变量，在.h中仅作声明。 规则1.2 头文件应当向稳定的方向包含； 一般而言，应当让不稳定的模块依赖于稳定的模块，就产品而言，即产品依赖于平台，平台依赖于标准库。 规则1.3 禁止头文件循环依赖并禁止包含用不到的头文件； 头文件循环依赖，比如a.h包含b.h，b.h包含c.h, c.h包含a.h, 这样就会导致任何一个头文件的更改，都会导致a.h/b.h/c.h全部编译一遍，如果是单向依赖，如a.h包含b.h, b.h包含c.h，而c.h可以不需要包含。 规则?1.4?总是编写内部#include保护符（即#Define 保护） 多个文件包含同一文件实际上可以通过良好的系统设计来避免，但是保险起见，我们要有防御式编程意识，即所以头文件都应当使用#Define防止头文件被重复包含，如下图所示： 规则 1.5?禁止在头文件中定义变量 因为在头文件中定义的变量很容易被其他.c 文件包含易造成重复定义而出错。 规则 1.6 当C++文件需调用C文件函数或者变量时，需要用extern “C”?声明； 因为C++语言支持函数重载，而C语言不支持，这样用C++编译器编译出的函数同时包含函数名与变量类型，而C语言则只存在函数名，因为需要通过该标识符来告诉C++编译器这部分代码需要按照C语言来进行编译链接，否则链接会出错，找不到该函数，具体使用方法如下： 2? 函数 规则2.1 ?一个函数仅完成一个功能 如果一个函数同时完成多项功能，不仅不利于维护，而且会大大增加系统的耦合性，不能够让读者清晰明白本函数的用途，因此保持此原则是写出优秀代码的关键。 规则2.2 ?重复代码应当尽可能提炼成函数 如果一直保持着“代码能用就不改”的原则，那么一大坨烟囱式的代码堆积，不仅容易出错，而且可读性差，十分不友好，往往这类代码存在着极大的优化空间，应当立马着手重构代码，即当一段代码出现2次，应当考虑消除，当重复代码出现3次，应当立刻着手消除。 规则2.3 ?避免函数过长，新增函数有效代码行数不应超过50行（非空非注释） 代码过长一般意味着函数实现功能不单一，可读性差，建议将内部相关算法步骤整合成函数，以便函数实现步骤清晰可见。另外，业界普遍认为一个函数允许的最大长度不应该超过当前整个屏幕，避免来回翻页影响阅读。 规则2.4 避免函数代码嵌套过深，新增函数代码块一般不应超过4层； 规则2.5 可重入函数应避免使用共享变量，若需要使用，则应通过互斥手段（关中断，信号量）来加以保护； 所谓可重入函数就是可同时被多个任务并发调用的函数，共享变量指的是全局变量与静态变量；不可重入函数即不可中断的函数，因为其内部使用了共享变量。 规则 2.5 设计高扇入，合理扇出的函数（小于7）的函数； 所谓高扇入即多个函数调用本函数，所谓高扇出即本函数调用了过多的函数；一般而言，在不破坏软件架构的前提下尽可能追求高扇入，扇出要适当，一般3-5为宜，过高则表示缺少中间层过渡，过低，如总是1，就会给堆栈空间造成不必要的压力。 规则 2.6 废弃代码坚决立刻删除； 所谓废弃代码就是没有被调用的函数或者变量以及相关临时测试代码，因为现代软件版本管理工具如Git完全可查看任意文件的修改历史，无需放在代码中占用空间，有时甚至会给代码维护带来一定的干扰，降低工作效率，得不偿失。 几点建议： 函数传入的不变参数应使用const； 检查函数所有输入参数的有效性； 函数的参数一般不应该超过5个； 在源文件范围内声明并定义的函数，除非外不可见，否则应当增加static关键字。 3 标识符命名与定义 规则 3.1 公司或者项目组应当采用统一的变量命名规则且定义清晰明确； 对于变量命名应当有统一规范，不应当百家齐放，保持统一风格为佳，如局部变量前缀为l_，全局变量前缀为g_?，是采用windows风格还是匈牙利命名法，最好有章可循，统一规范。 规则 3.2 除了常见的缩写，不使用单词缩写，以免词不达意； 如argument 可缩写为 arg， clock 可缩写为 clk，device可缩写为dev， error可缩写为err， increment 可缩写为inc，message 可缩写为 msg，synchronize 可缩写为sync ，temp 可缩写为tmp等。 规则 3.3 宏必须全部使用大写； 规则 3.4 应当尽量不使用全局变量或者静态变量； 因为全局变量的大量使用，会大大破坏软件架构，而且给代码维护带来极大的不便，有时候如果不注意很容易出现全局变量被编译器优化，导致多