软件编程规范总则CHECKLIST1
软件开发流程和check list
在Sensor上安置好白屏光源 调节曝光时间，颜色增益，使得画面呈现灰色，并确认整体
亮度在最高亮度的80%左右 采集影像图片
Mean and Std
测试目的：
测试图片是否处于Middle Level
测试方法：
1.将图像分割为A，B两个区域，A区为图像中心25%区域， B区为图像周边区域
2）将每个通道分成M*N块数据块，并统计每块数据块的均值，记 录数据Rmean[m*n],Bmean[m*n],Gmean[m*n]， ROG[m*n],BOG[m*n]
3）统计每个色块的均值最大及最小值，再求积，则得到每个色块 的uniformity，作为测试数据
4）取出中心位置的ROGRef，BOGRef，再将m*n个ROG，BOG与 ROGRef，BOGRef进行比较，取差异最大值作为测试数据
高分辨率
低分辨率
对上图中大于10的亮度进行统计求和，再取自然对数，数值 分别为：12.2311 和 10.1364
从而可指定标准区分出良品不良品。
Line Chart Histogram
测试方法：
按亮度绘出对应视场角图像的直方图 统计两个波峰间的亮度所占的比例 测试图像及对应直方图如下：
测试方法：
工作电流：通过对Die的寄存器进行设置，让其处于功耗最 高的状态，测量其3路电源的电流。
待机电流：通过硬件或软件让Die进入待机状态，并调整 PWDN、RESET、MCLK、SDA、SCL的状态，调整AVDD、 DOVDD、DVDD的电压，让Die的功耗最低，测量总电流。
Middle Level Test
使用单位定义(3位字符)：
TSV事业部→TSV
WOC事业部→WLC
软件编程规范总则
目录1 排版62 注释113 标识符命名184 可读性205 变量、结构226 函数、过程287 可测性368 程序效率409 质量保证4410 代码编辑、编译、审查5011 代码测试、维护5212 宏531 排版¹1-1：程序块要采用缩进风格编写，缩进的空格数为4个。
说明：对于由开发工具自动生成的代码可以有不一致。
¹1-2：相对独立的程序块之间、变量说明之后必须加空行。
示例：如下例子不符合规范。
if (!valid_ni(ni)){... // program code}repssn_ind = ssn_data[index].repssn_index;repssn_ni = ssn_data[index].ni;应如下书写if (!valid_ni(ni)){... // program code}repssn_ind = ssn_data[index].repssn_index;repssn_ni = ssn_data[index].ni;¹1-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
示例：perm_count_msg.head.len = NO7_TO_STAT_PERM_COUNT_LEN+ STAT_SIZE_PER_FRAM * sizeof( _UL );act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied= stat_poi[index].occupied;act_task_table[taskno].duration_true_or_false= SYS_get_sccp_statistic_state( stat_item );report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER)&& (n7stat_stat_item_valid (stat_item))&& (act_task_table[taskno].result_data != 0));¹1-4：循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
软件编程规范
软件编程规范软件编程规范是一套旨在提高软件开发质量和可维护性的准则和规范。
它们定义了编程风格、命名约定、代码组织结构、注释规范等方面的规则，旨在提高代码的可读性、可理解性和可维护性。
下面是一些常见的软件编程规范：1. 命名约定变量、函数、类、文件等命名要具有描述性，使用有意义的名称，遵循驼峰命名法或下划线命名法。
避免使用单个字母或无意义的缩写。
2. 缩进和空格使用一致的缩进风格，通常是使用4个空格或者制表符。
在运算符两侧和逗号后添加空格，以提高可读性。
3. 注释规范在代码中添加清晰的注释，解释代码的逻辑和意图。
注释应该与代码一起更新，以保持同步。
注释长度应适中，不要过于冗长，但也不要过于简单。
4. 异常处理在必要的地方添加异常处理机制，以便在程序出错时能够恢复或处理异常情况。
避免使用捕捉所有异常的通配符异常处理语句，应该明确地捕获和处理特定类型的异常。
5. 函数和方法函数和方法应该尽可能地短小和单一责任原则。
函数和方法名应该具有描述性，不要使用虚词或无意义的名称。
6. 代码注重可重用性代码应该根据功能进行模块化和组织，以便可以被其他程序或模块重复使用。
避免使用全局变量和硬编码的常量，而是使用参数和配置文件来实现可配置性。
7. 类和对象类和对象应该具有清晰的结构和接口，并按照单一责任原则进行设计。
类和对象之间的关系应该清晰明确，避免过度耦合。
8. 设计模式应该根据实际需求选择合适的设计模式，以提高代码的可扩展性和可维护性。
常见的设计模式包括单例模式、工厂模式、观察者模式等。
9. 版本控制使用版本控制软件进行代码管理，定期提交代码，并为每个提交添加有意义的注释。
遵循版本控制的最佳实践，例如分支管理和代码审查。
10. 测试和调试编写测试代码来验证程序的正确性和健壮性。
使用调试工具来分析和解决程序的错误和异常情况。
以上只是一些常见的软件编程规范，具体的规范可能因编程语言、项目需求和团队约定而有所不同。
遵循软件编程规范可以提高代码质量和可维护性，减少程序错误和调试时间，有助于提高软件开发效率和团队协作效果。
规范编程管理制度
规范编程管理制度第一章总则第一条为了规范和管理公司编程工作，提高编程效率和质量，制定本管理制度。
第二条本制度适用于公司内的所有编程工作，包括但不限于软件开发、网站建设、移动应用开发等。
第三条公司全体员工必须遵守本制度，否则将受到相应的处罚。
第四条公司将按照本制度对编程工作进行管理和评估，以确保项目按时完成、质量可控。
第五条公司将不断完善本制度，根据实际情况进行调整和修订。
第二章编程管理组织架构第六条公司设立编程管理部门，负责全公司的编程工作管理和协调。
第七条编程管理部门主要包括以下职能部门：（一）软件开发部：负责公司软件产品的开发和维护工作。
（二）网站建设部：负责公司网站的建设和维护工作。
（三）移动应用开发部：负责公司移动应用的开发和维护工作。
第八条公司编程管理部门负责制定编程工作计划、安排编程资源、指导和督促编程工作的进行，保证编程项目按时完成、质量可控。
第九条公司编程管理部门负责对编程工作进度和质量进行监督和评估，及时发现和解决问题，确保项目进展顺利。
第十条公司编程管理部门负责归档编程项目的相关文档和资料，以备将来的查阅和分析工作。
第三章编程管理流程第十一条公司编程管理部门负责制定编程项目立项流程，包括项目可行性研究、需求分析、技术方案设计等。
第十二条每个编程项目立项都需要提出立项申请，经编程管理部门审批通过后方可启动项目。
第十三条编程项目启动后，编程管理部门负责设置编程进度计划和任务分配，确保各项工作按时完成。
第十四条在编程项目进行过程中，编程管理部门负责监督和检查各项任务的进展，及时发现问题并给予解决。
第十五条编程项目完成后，编程管理部门将对项目进行总结和评估，总结经验教训并提出改进意见。
第十六条每个编程项目都需要编程管理部门的最终确认，方可正式发布或交付使用。
第四章编程管理制度第十七条公司严格遵守国家相关法律法规和编程管理方面的规定，确保编程工作的合法性。
第十八条公司制定编程管理规范和标准，明确编程工作的要求和规范。
软件编程规范总则
软件编程规范总则1. 前言软件编程规范是指在软件开发过程中，为了提高代码质量、可读性和可维护性，制定的一系列约定和规则。
本编程规范总则旨在统一团队开发中的编码风格，提高代码的可读性和可维护性。
2. 命名规范良好的命名规范可以提高代码的可读性，建议按照以下规则进行命名：2.1 文件和目录命名•文件和目录名称应采用有意义的英文单词或短语拼写，使用小写字母和下划线进行分隔。
•目录名称应统一使用复数形式。
•文件名称应能准确描述文件的内容。
2.2 变量和函数命名•变量和函数的命名应采用小驼峰命名法，即首字母小写，后续单词首字母大写，不使用下划线。
•变量名应具有明确的含义，并尽量避免使用缩写。
•函数名应能准确描述函数的功能。
2.3 类和接口命名•类和接口的命名应采用大驼峰命名法，即每个单词的首字母都大写，没有下划线。
•类名应具有明确的含义，并使用名词或名词短语。
•接口名应具有明确的含义，并以“able”或“ible”结尾，表示具有某种能力或约束。
3. 代码风格统一的代码风格可以提高代码的可读性，方便团队协作和代码维护。
以下是一些常见的代码风格规则：3.1 缩进和换行•使用 4 个空格进行缩进，不使用制表符。
•每行代码不应超过 80 个字符。
•适当的换行可以增强代码的可读性。
3.2 空格和括号•使用空格将运算符与操作数分隔开，可以提高可读性。
•在逗号、分号、冒号后面使用空格。
•左大括号不另起一行，放在行尾，与关键字或函数名之间用一个空格隔开。
3.3 注释规范良好的注释可以方便他人理解代码的意图。
以下是一些注释规范建议：- 函数、类和接口应该有相应的注释，描述其功能、参数和返回值。
- 重要的代码片段应添加单行注释，解释代码的意图和设计思路。
- 长段的注释使用块注释，并应在开头写明注释的创建时间和作者。
4. 异常处理异常处理是保证代码稳定性的重要步骤。
以下是一些异常处理的规范建议： -在可能发生异常的地方使用 try-catch 块处理异常。
软件编程规范总则(DOC 8页)
¹7-14：用调测开关来切换软件的DEBUG版与正式版，而不要同时存在正式版本与DEBUG版本的不一致源文件，以减少保护的难度。
是[ ]否[ ]免[ ]
¹7-15：软件的DEBUG版本与发行版本应该统一保护，不同意分家，同时要时刻注意保证两个版本在实现功能上的一致性。
是[ ]否[ ]免[ ]
¹5-4：当向公共变量传递数据时，要十分小心，防止赋与不合理的值或者越界等现象发生。
¹5-5：防止局部变量与公共变量同名。
¹5-6：严禁使用未经初始化的变量作为右值。
¹6-1：对所调用函数的错误返回码要认真、全面地处理。
是[ ]否[ ]免[ ]
¹6-2：明确函数功能，精确（而不是近似）地实现函数设计。
是[ ]否[ ]免[ ]
¹8-5：循环体内工作量最小化。
是[ ]否[ ]免[ ]
¹9-1：在软件设计过程中构筑软件质量。
是[ ]否[ ]免[ ]
¹9-2：代码质量保证优先原则
是[ ]否[ ]免[ ]
¹9-3：只引用属于自己的存贮空间。
是[ ]否[ ]免[ ]
¹9-4：防止引用已经释放的内存空间。
是[ ]否[ ]免[ ]
是[ ]否[ ]免[ ]
¹11-1：单元测试要求至少达到语句覆盖。
是[ ]否[ ]免[ ]
¹11-2：单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
是[ ]否[ ]免[ ]
¹11-3：清理、整理或者优化后的代码要通过审查及测试。
是[ ]否[ ]免[ ]
¹11-4：代码版本升级要通过严格测试。
是[ ]否[ ]免[ ]
10
¹1-10：程序块的分界符（如C/C++语言的大括号‘{’与‘}’）应各独占一行同时位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义与if、for、do、while0、switch、case语句中的程序都要使用如上的缩进方式。
(important)编程规范CHECKLIST
○建议 头文件是否完整？
头文件是否使用了ifndef/define/endif 结构产生预处理 防止头文件被重复引用。 块？ 是否用#include<filename.h> 格式来引用标准库的头文 ●规则 编译器将从标准库目录开始搜索。 件？ 是否用#include“filename.h”格式来引用非标准库的头 ●规则 编译器将从用户的工作目录开始搜索。 文件？ 在C++语法中，类的成员函数可以在声明的同时被定义，并自动成为内联函数。但会破坏了风格，所 ○建议 头文件中是否只存放“声明”而不存放“定义”？ 以建议函数的定义和声明分开，无论该函数体有多小。 ○建议 是否在头文件中出现类似extern int value 的声明？ 不提倡使用全局变量，尽量不要在头文件中出现类似的声明。 主要内容： 1.定义文件开头处的版权和版本声明； ○建议 定义文件是否完整？ 2.对一些头文件的引用； 3.程序的实现体（包括数据和代码）。 程序版式 ●规则 声明、函数之间的空行是否合理？ 在每个类声明之后、每个函数定义结束之后都要加空行。 ●规则 函数体内的空行是否合理？ 在一个函数体内，逻辑上密切相关的语句之间不加空行，其他地方应加空行分隔。 ●规则 一行代码做了多少事情？ 一行代码只做一件事情，如定义一个变量，或只写一条语句——容易阅读，便于注释。 ●规则
const的优点： 在C++中，是否用const常量取代宏常量（#define定义的常 1.const常量有数据类型，而宏常量没有数据类型。 量）？ 2.有些集成化的调试工具可以对const常量进行调试，但是不能对宏常量进行调试。 需要对外公开的常量放在头文件中，不需要对外公开的常量放在定义文件中。为了便于管理，可以 ●规则 将常量定义放在头文件还是定义文件中？ 将不同模块的常量存放在一个公共的头文件中。 如果一个常量和其他常量密切相关，是否应当在定义中包 ●规则 如果某一常量与其他常量密切相关，应在定义中包含这种关系，而不应给出一些孤立的值。 含着这种关系？ 1.const数据成员只在某个对象生存期内是常量，对于整个类而言是可变的。 2.不能在类声明中初始化const数据成员。其初始化只能在类构造函数的初始化表中进行。 ○建议 是否误解了类中的const数据成员？ 3.若要建立在整个类中都恒定的常量，可以用类中的枚举常量来实现。 枚举类优缺点：1.不会占用对象的存储空间，在编译时被全部求值。 2.他的隐含数据类型是整型，其最大值有限，且不能表示浮点数。 函数设计 ○建议 检查函数的功能和规模。 ●规则 参数的书写是否完整？若没有参数时，是否置空？ 函数的功能要单一，不要设计多用途的函数。函数的规模要小，尽量控制在50行代码之内。 参数的书写要完整，不能贪图省事而只写参数的类型而省略参数名字。如果函数没有参数，则用 void填充。
编程规范管理制度
编程规范管理制度第一章总则第一条目的和依据为规范企业内部编程工作、提高编码质量和开发效率，保证项目的可维护性和稳定性，订立本规章制度。
第二条适用范围本规章制度适用于企业全体编程人员，包含但不限于软件开发工程师、前端工程师、测试工程师等。
第三条基本原则1.符合软件工程理论和行业标准；2.提倡简洁、清楚、易于理解和维护的编码风格；3.强调团队协作和沟通本领，建立良好的开发环境；4.保护知识产权，禁止抄袭和盗用他人代码。
第二章编码风格规范第四条命名规定1.类、接口和枚举的命名使用驼峰命名法，首字母大写；2.变量、方法和函数的命名使用驼峰命名法，首字母小写；3.常量的命名使用全大写，单词间用下划线分隔；4.包名使用小写字母，单词间用点号分隔。
第五条代码格式化1.使用4个空格作为缩进；2.代码行长度不超出80个字符；3.每行代码只包含一个语句，避开多个语句写在一行；4.在逻辑关系较为多而杂的地方，使用恰当的空行和缩进来加强可读性。
1.类、接口、方法和常量应添加必需的注释，描述其功能和用途；2.注释应采用英文，并保持简洁明白，避开使用无意义的注释；3.需要供应方法使用示例的注释时，应供应有效的代码示例。
第七条异常处理1.捕获异常时，应避开捕获全部异常，要有明确的异常处理逻辑；2.异常处理应依据具体情况选择合适的方式，如日志记录、错误提示等；3.不建议在finally块中使用return语句，以避开产生难以预料的结果。
第三章版本掌控规范第八条版本管理1.全部项目代码使用版本掌控工具进行管理，介绍使用Git；2.每个项目应创建独立的代码仓库，避开混淆和冲突；3.对于每次代码修改，都要记录提交日志，明确描述修改内容；4.在开发过程中，及时拉取最新代码，避开冲突和代码丢失。
第九条分支管理1.开发新功能、解决bug等工作，可以在主分支创建子分支进行开发；2.提交到主分支前，需要进行代码审查和测试，确保质量；3.主分支上的代码必需是稳定和可用的版本。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
¹7-7：不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
是[ ]否[ ]免[ ]
¹7-8：对较复杂的断言加上明确的注释。
是[ ]否[ ]免[ ]
¹7-9：用断言确认函数的参数。
是[ ]否[ ]免[ ]
¹7-10：用断言保证没有定义的特性或功能不被使用。
是[ ]否[ ]免[ ]
¹7-1：在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并且要有详细的说明。
是[ ]否[ ]免[ ]
¹7-2：在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。
是[ ]否[ ]免[ ]
¹7-3：编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为（模块中的）一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
是[ ]否[ ]免[ ]
¹7-4：在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细分析并优化测试用例，以提高测试效率。
是[ ]否[ ]免[ ]
¹7-5：使用断言来发现软件问题，提高代码可测性。
是[ ]否[ ]免[ ]
¹7-6：用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
¹7-11：用断言对程序开发环境（OS/Compiler/Hardware）的假设进行检查。
是[ ]否[ ]免[ ]
¹7-12：正式软件产品中应把断言及其它调测代码去掉（即把有关的调测开关关掉）。
是[ ]否[ ]免[ ]
¹7-13：在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。
是[ ]否[ ]免[ ]
¹8-5：循环体内工作量最小化。
是[ ]否[ ]免[ ]
¹9-1：在软件设计过程中构筑软件质量。
是[ ]否[ ]免[ ]
¹9-2：代码质量保证优先原则
是[ ]否[ ]免[ ]
¹9-3：只引用属于自己的存贮空间。
是[ ]否[ ]免[ ]
¹9-4：防止引用已经释放的内存空间。
是[ ]否[ ]免[ ]
¹9-9：系统运行之初，要初始化有关变量及运行环境，防止未经初始化的变量被引用。
是[ ]否[ ]免[ ]
¹9-10：系统运行之初，要对加载到系统中的数据进行一致性检查。
是[ ]否[ ]免[ ]
¹9-11：严禁随意更改其它模块或系统的有关设置和配置。
是[ ]否[ ]免[ ]
¹9-12：不能随意改变与其它模块的接口。
11
¹1-11：在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或者前后要加空格；进行非对等操作时，如果是关系密切的立即操作符（如－>），后不应加空格。
是[ ]否[ ]免[ ]
¹2-1：一般情况下，源程序有效注释量必须在20％以上。
是[ ]否[ ]免[ ]
¹2-2：说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。
是[ ]否[ ]免[ ]
4
¹1-4：循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
是[ ]否[ ]免[ ]
5
¹1-5：若函数或过程中的参数较长，则要进行适当的划分。
是[ ]否[ ]免[ ]
6
¹1-6：不允许把多个短语句写在一行中，即一行只写一条语句。
是[ ]否[ ]免[ ]
¹7-14：用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。
是[ ]否[ ]免[ ]
¹7-15：软件的DEBUG版本和发行版本应该统一维护，不允许分家，并且要时刻注意保证两个版本在实现功能上的一致性。
是[ ]否[ ]免[ ]
是[ ]否[ ]免[ ]
¹10-1：打开编译器的所有告警开关对程序进行编译。
是[ ]否[ ]免[ ]
¹10-2：在产品软件（项目组）中，要统一编译开关选项。
是[ ]否[ ]免[ ]
¹10-3：通过代码走读及审查方式对代码进行检查。
是[ ]否[ ]免[ ]
¹10-4：测试部测试产品之前，应对代码进行抽查及评审。
执行情况
说明
1
¹1-1：程序块要采用缩进风格编写，缩进的空格数为4个。
是[ ]否[ ]免[ ]
2
¹1-2：相对独立的程序块之间、变量说明之后必须加空行。
是[ ]否[ ]免[ ]
3
¹1-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。
是[ ]否[ ]免[ ]
¹2-6：注释的内容要清楚、明了，含义准确，防止注释二义性。
是[ ]否[ ]免[ ]
¹2-7：避免在注释中使用缩写，特别是非常用缩写。
是[ ]否[ ]免[ ]
¹2-8：注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
是[ ]否[ ]免[ ]
¹11-1：单元测试要求至少达到语句覆盖。
是[ ]否[ ]免[ ]
¹11-2：单元测试开始要跟踪每一条语句，并观察数据流及变量的变化。
是[ ]否[ ]免[ ]
¹11-3：清理、整理或优化后的代码要经过审查及测试。
是[ ]否[ ]免[ ]
¹11-4：代码版本升级要经过严格测试。
是[ ]否[ ]免[ ]
¹6-3：编写可重入函数时，应注意局部变量的使用(如编写C/C++语言的可重入函数时，应使用auto即缺省态局部变量或寄存器变量)。
是[ ]否[ ]免[ ]
¹6-4：编写可重入函数时，若使用全局变量，则应通过关中断、信号量（即P、V操作）等手段对其加以保护。
是[ ]否[ ]免[ ]
¹4-2：避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替。
是[ ]否[ ]免[ ]
¹5-1：去掉没必要的公共变量。
是[ ]否[ ]免[ ]
¹5-2：仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。
¹5-3：明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
¹9-5：过程/函数中分配的内存，在过程/函数退出之前要释放。
是[ ]否[ ]免[ ]
¹9-6：过程/函数中申请的(为打开文件而使用的)文件句柄，在过程/函数退出之前要关闭。
是[ ]否[ ]免[ ]
¹9-7：防止内存操作越界。
是[ ]否[ ]免[ ]
¹9-8：认真处理程序所能遇到的各种出错情况。
是[ ]否[ ]免[ ]
¹5-4：当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
¹5-5：防止局部变量与公共变量同名。
¹5-6：严禁使用未经初始化的变量作为右值。
¹6-1：对所调用函数的错误返回码要仔细、全面地处理。
是[ ]否[ ]免[ ]
¹6-2：明确函数功能，精确（而不是近似）地实现函数设计。
是[ ]否[ ]免[ ]
¹11-5：使用工具软件对代码版本进行维护。
是[ ]否[ ]免[ ]
¹11-6：正式版本上软件的任何修改都应有详细的文档记录。
是[ ]否[ ]免[ ]
¹12-1：用宏定义表达式时，要使用完备的括号。
是[ ]否[ ]免[ ]
¹9-13：充分了解系统的接口之后，再使用系统提供的功能。
是[ ]否[ ]免[ ]
¹9-14：编程时，要防止差1错误。
是[ ]否[ ]免[ ]
¹9-15：要时刻注意易混淆的操作符。当编完程序后，应从头至尾检查一遍这些操作符，以防止拼写错误。
是[ ]否[ ]免[ ]
¹9-16：有可能的话，if语句尽量加上else分支，对没有else分支的语句要小心对待；switch语句必须有default分支。
是[ ]否[ ]免[ ]
¹2-15：对于switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，必须在该case语句处理完、下一个case语句前加上明确的注释。
是[ ]否[ ]免[ ]
¹3-1：标识符的命名要清晰、明了，有明确含义，同时使用完整的单词或大家基本可以理解的缩写，避免使人产生误解。
是[ ]否[ ]免[ ]
10
¹1-10：程序块的分界符（如C/C++语言的大括号‘{’和‘}’）应各独占一行并且位于同一列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while0、switch、case语句中的程序都要采用如上的缩进方式。
是[ ]否[ ]免[ ]
是[ ]否[ ]免[ ]
¹2-3：源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。
是[ ]否[ ]免[ ]
¹2-4：函数头部应进行注释，列出：函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。
是[ ]否[ ]免[ ]
¹2-5：边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
是[ ]否[ ]免[ ]
¹3-5：命名规范必须与所使用的系统ቤተ መጻሕፍቲ ባይዱ格保持一致，并在同一项目中统一，比如采用UNIX的全小写加下划线的风格或大小写混排的方式，不要使用大小写与下划线混排的方式。