软件设计更多地是一种工程，而不是一种个人艺术。如果不统一编程规范，最终写出的程序，其可读性将较差，这不仅给代码的理解带来障碍，增加维护阶段的工作量，同时不规范的代码隐含错误的可能性也比较大。 分析表明，编码阶段产生的错误当中，语法错误大概占20%左右，而由于未严格检查软件逻辑导致的错误、函数（模块）之间接口错误及由于代码可理解度低导致优化维护阶段对代码的错误修改引起的错误则占了一半以上。 可见，提高软件质量必须降低编码阶段的错误率。如何有效降低编码阶段的错误呢？这需要制定详细的软件编程规范，并培训每一位程序员，最终的结果可以把编码阶段的错误降至10%左右，同时也降低了程序的测试费用，效果相当显著。
本文从代码的可维护性（可读性、可理解性、可修改性）、代码逻辑与效 率、函数（模块）接口、可测试性四个方面阐述了软件编程规范，规范分成规则和建议两 种，其中规则部分为强制执行项目，而建议部分则不作强制，可根据习惯取舍。 1．排版 规则1 程序块使用缩进方式，函数和标号使用空格缩进，程序段混合使用TAB和空格缩进。缩进的目的是使程序结构清晰，便于阅读和理解。 默认宽度应为8个空格，由于Word中为4个空格，为示范清晰，此处用2个代替(下同)。 例如： MOV R1, #00H MOV R2, #00H MOV PMR, #PMRNORMAL MOV DPS, #FLAGDPTR MOV DPTR, #ADDREEPROM read1kloop: read1kpage: INC R1 MOVX A, @DPTR MOV SBUF, A JNB TI, $ CLR TI INC DPTR CJNE R1, #20H, read1kpage INC R2 MOV R1, #00H CPL WDI CJNE R2, #20H, read1kloop ;END OF EEPROM 规则2 在指令的操作数之间的，使用空格进行间隔，采用这种松散方式编写代码的 目的是使代码更加清晰。 例如： CJNE R2, #20H, read1kloop ;END OF EEPROM
规则3 一行最多写一条语句。 规则4 变量定义时，保持对齐。便于阅读和检查内存的使用情况。 例如： RegLEDLOSS EQU 30H ; VARIABLE ; TESTLED==RegLEDLOSS.0 RegLEDRA EQU 31H ; VARIABLE RUNLED_Flag EQU 32H ; VARIABLE ; 256ms改变一次RUNLED状态 RUNLED_Def EQU 10H ; STATIC ; 16*32ms=500ms改变一次LED状态
2．注释 注释的原则是有助于对程序的阅读理解，注释不宜太多也不能太少，太少不利于代码理解，太多则会对阅读产生干扰，因此只在必要的地方才加注释，而且注释要准确、易懂、尽可能简洁。注释量一般控制在30%到50%之间。 规则1 程序在必要的地方必须有注释，注释要准确、易懂、简洁。 例如如下注释意义不大： MOV DXCE1COUNTER, #00H ; 将DXCE1COUNTER赋值为0 而如下的注释则给出了额外有用的信息： JNZ PcComm_Err ; 假如校验出错 规则2 注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语 句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。 规则3 头文件、源文件的头部，应进行注释。注释必须列出：文件名、作者、目的、功能、修改日志等。 规则4 函数头部应进行注释，列出：函数的目的、功能、输入参数、输出参数、涉及到的通用变量和寄存器、调用的其他函数和模块、修改日志等。对一些复杂的函数，在注释中最好提供典型用法。 规则5 对重要代码段的功能、意图进行注释，提供有用的、额外的信息。并在该代码段的结束处加一行注释表示该段代码结束。 规则6 对于所有的常量，变量，数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其含义。 规则 7 维护代码时，要更新相应的注释，删除不再有用的注释。保持代码、注释的一致性，避免产生误解。 3．命名 规则 1 标识符缩写 形成缩写的几种技术： 1) 去掉所有的不在词头的元音字母。如screen写成scrn, primtive写成p rmv。 2) 使用每个单词的头一个或几个字母。如Channel Activation写成ChanA ctiv，Release Indication写成RelInd。 3) 使用变量名中每个有典型意义的单词。如Count of Failure写成FailC nt。 4) 去掉无用的单词后缀 ing, ed等。如Paging Request写成PagReq。 5) 使用标准的或惯用的缩写形式（包括协议文件中出现的缩写形式）。 如BSIC(Base Station Identification Code)、MAP(Mobile Application Part)。 关于缩写的准则： 1) 缩写应该保持一致性。如Channel不要有时缩写成Chan，有时缩写成C h。Length有时缩写成Len，有时缩写成len。 2) 在源代码头部加入注解来说明协议相关的、非通用缩写。 3) 标识符的长度不超过12个字符。 规则2 变量命名约定：<前缀> + 主体 ; 注释 变量命名要考虑简单、直观、不易混淆。 前缀是可选项，表示变量类型，由于汇编中变量多是单字节变量，所以单字 节变量可以不加前缀，对于bit和双字节型变量，使用小写的b和d作为前缀表示。 主体是必选项，可多个单词(或缩写)合在一起，每个单词首字母大写，其余 部分小写。 规则3 常量的命名 常量的命名规则：单词的字母全部大写，各单词之间用下划线隔开。 规则4 函数的命名 单词首字母为大写，其余均为小写。函数名应以一个动词开头，即函数名应 类似一个动词断语或祈使句。 例如：Test_Protect， Check_EEPROM， Init_Para 4．可维护性 规则1 函数和过程中关系较为紧密的代码尽可能相邻。 规则2 每个函数的源程序行数原则上应该少于200行。 对于消息分流处理函数，完成的功能统一，但由于消息的种类多，可能超过2 00行的限制，不属于违反规定。 规则3 语句嵌套层次不得超过5层。 嵌套层次太多，增加了代码的复杂度及测试的难度，容易出错，增加代码维 护的难度。 规则4 避免相同的代码段在多个地方出现。 当某段代码需在不同的地方重复使用时，应根据代码段的规模大小使用函数 调用或宏调用的方式代替。这样，对该代码段的修改就可在一处完成，增强代码的可维护 性。 规则5 每个函数完成单一的功能，不设计多用途面面俱到的函数。 多功能集于一身的函数，很可能使函数的理解、测试、维护等变得困难。使 函数功能明确化，增加程序可读性，亦可方便维护、测试。 规则6 在函数的项目维护文档中，应该指出软件适用的硬件平台及版本。 建议1 使用专门的初始化函数对所有的公共变量进行初始化。 5．程序正确性、效率 规则1 严禁使用未经初始化的变量。 引用未经初始化的变量可能会产生不可预知的后果，特别是引用未经初始化 的指针经常会导致系统崩溃，需特别注意。 规则2 防止内存操作越界。 说明：内存操作越界是软件系统主要错误之一，后果往往非常严重。 规则3 注意变量的有效取值范围，防止表达式出现上溢或下溢。 规则4 防止易混淆的指令和操作数拼写错误。 规则5 避免函数中不必要语句，防止程序中的垃圾代码，预留代码应以注释的方式 出现。 程序中的垃圾代码不仅占用额外的空间，而且还常常影响程序的功能与性 能，很可能给程序的测试、维护等造成不必要的麻烦。 规则6 通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空 间效率。 这种方式是解决软件空间效率的根本办法。 规则7 循环体内工作量最小化。 应仔细考虑循环体内的语句是否可以放在循环体之外，使循环体内工作量最 小，从而提高程序的时间效率。 规则8 在多重循环中，应将最忙的循环放在最内层。 规则9 避免循环体内含判断语句，将与循环变量无关的判断语句移到循环体外。 目的是减少判断次数。循环体中的判断语句是否可以移到循环体外，要视程 序的具体情况而言，一般情况，与循环变量无关的判断语句可以移到循环体外，而有关的 则不可以。 规则10 中断和恢复 中断程序应该尽量短，应该在中断中进行标记，在主程序中处理。但实时性 很高的程序段例外。 中断时应该保存所有涉及到的通用变量和寄存器，如A, PSW, DPTR等。 规则11 堆栈设置 堆栈对于程序非常重要，对于堆栈的设置要合理。堆栈太小，在嵌套调用和容易溢出，造成系统故障；堆栈太大，浪费RAM资源。 为了节约堆栈资源，中断时要求不要保存太多资源，中断嵌套和程序嵌套层 数不要太多，尽量不要超过5层。这就要求合理的划分功能模块。 规则12 看门狗 看门狗电路用于在单片机死机时自动复位。单片机需要定时向看门狗发送脉 冲，俗称”喂狗”。喂狗不可太勤，这样看门狗没有起到作用；也不可太慢，这样容易造成 单片机复位。正确的喂狗应该在主循环中进行，最好是建立一个独立的系统监控进程。不 可以在定时中断中喂狗，应为单片机有时可能会在主循环中死掉。 6．接口 规则1 去掉没有必要的公共变量，编程时应尽量少用公共变量。 公共变量是增大模块间耦合的原因之一，故应减少没必要的公共变量以降低 模块间的耦合度。应该构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数 只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。 规则2 当向公共变量传递数据时，要防止越界现象发生。 对公共变量赋值时，若有必要应进行合法性检查，以提高代码的可靠性、稳 定性。 规则3 尽量不设计多参数函数，将不使用的参数从接口中去掉，降低接口复杂度， 减少函数间接口的复杂度。 规则4 对所调用函数的返回码要仔细、全面地处理。 防止把错误传递到后面的处理流程。如有意不检查其返回码，应明确指明。 规则5 检查接口函数所有输入参数的有效性。 规则6 检查函数的所有非参数输入，如外部数据、公共变量等。 7．代码可测性 规则1 模块编写应该有完善的测试方面的考虑。 规则2 源代码中应该设计了代码测试的内容。 在编写代码之前，应预先设计好程序调试与测试的方法和手段，并设计好各 种调测开关及相应测试代码。 程序的调试与测试是软件生存周期中很重要的一个阶段，如何对软件进行较 全面、高率的测试并尽可能地找出软件中的错误就成为很关键的问题。因此在编写源代码 之前，除了要有一套比较完善的测试计划外，还应设计出一系列代码测试手段，为单元测 试、集成测试及系统联调提供方便。 规则3 在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调 测开关及相应函数，并且要有详细的说明。本规则是针对项目组或产品组的。
规则4 在同一项目组或产品组内，调测打印出的信息串的格式要有统一的形式。信息串中至少要有所在模块名（或源文件名）及行号。统一的调测信息格式便于集成测试。 规则5 正式软件产品中应把调测代码去掉（即把有关的调测开关关掉）。 规则6 用调测开关来切换软件的DEBUG版和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。 规则7 在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。 即有测试代码的软件和关掉测试代码的软件，在功能行为上应一致。 规则8 发现错误应该立即修改，并且若有必要记录下来。 规则9 开发人员应坚持对代码进行彻底的测试（单元测试），而不依靠他人或测试组来发现问题。 规则10 清理、整理或优化后的代码要经过审查及测试。 规则11 代码版本升级要经过严格测试。 8．代码编译 规则1 打开编译器的所有告警开关对程序进行编译。 防止隐藏可能是错误的告警。 规则2 某些语句经编译后产生告警，但如果你认为它是正确的，那么应通过某种手 段去掉告警信息。