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写成prmv。

2) 使用每个单词的头一个或几个字母。如Channel Activation写成ChanActiv，Release

Indication写成RelInd。

3) 使用变量名中每个有典型意义的单词。如Count of Failure写成FailCnt。

4) 去掉无用的单词后缀 ing, ed等。如Paging Request写成PagReq。

5) 使用标准的或惯用的缩写形式(包括协议文件中出现的缩写形式)。如BSIC(Base Station

Identification Code)、MAP(Mobile Application Part)。

关于缩写的准则：

1) 缩写应该保持一致性。如Channel不要有时缩写成Chan，有时缩写成Ch。Length有时缩写成Len，有时缩写成len。

2) 在源代码头部加入注解来说明协议相关的、非通用缩写。

3) 标识符的长度不超过12个字符。

规则2

变量命名约定：<前缀> + 主体 ; 注释

变量命名要考虑简单、直观、不易混淆。

前缀是可选项，表示变量类型，由于汇编中变量多是单字节变量，所以单字节变量可以不加前缀，对于bit和双字节型变量，使用小写的b和d作为前缀表示。

主体是必选项，可多个单词(或缩写)合在一起，每个单词首字母大写，其余部分小写。

规则3

常量的命名

常量的命名规则：单词的字母全部大写，各单词之间用下划线隔开。

规则4

函数的命名

单词首字母为大写，其余均为小写。函数名应以一个动词开头，即函数名应类似一个动词断语或祈使句。

例如：Test_Protect， Check_EEPROM， Init_Para

4.可维护性

规则1

函数和过程中关系较为紧密的代码尽可能相邻。

规则2

每个函数的源程序行数原则上应该少于200行。

对于消息分流处理函数，完成的功能统一，但由于消息的种类多，可能超过200行的限制，不属于违反规定。

规则3

语句嵌套层次不得超过5层。

嵌套层次太多，增加了代码的复杂度及测试的难度，容易出错，增加代码维护的难度。

规则4

避免相同的代码段在多个地方出现。

当某段代码需在不同的地方重复使用时，应根据代码段的规模大小使用函数调用或宏调用的方式代替。这样，对该代码段的修改就可在一处完成，增强代码的可维护性。

规则5

每个函数完成单一的功能，不设计多用途面面俱到的函数。

多功能集于一身的函数，很可能使函数的理解、测试、维护等变得困难。使函数功能明确化，增加程序可读性，亦可方便维护、测试。

规则6

在函数的项目维护文档中，应该指出软件适用的硬件平台及版本。

建议1

使用专门的初始化函数对所有的公共变量进行初始化。

5.程序正确性、效率

规则1

严禁使用未经初始化的变量。

引用未经初始化的变量可能会产生不可预知的后果，特别是引用未经初始化的指针经常会导致系统崩溃，需特别注意。

规则2

防止内存操作越界。

说明：内存操作越界是软件系统主要错误之一，后果往往非常严重。

规则3

注意变量的有效取值范围，防止表达式出现上溢或下溢。

规则4

防止易混淆的指令和操作数拼写错误。

规则5

避免函数中不必要语句，防止程序中的垃圾代码，预留代码应以注释的方式出现。

程序中的垃圾代码不仅占用额外的空间，而且还常常影响程序的功能与性能，很可能给程序的测试、维护等造成不必要的麻烦。

规则6

通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空间效率。

这种方式是解决软件空间效率的根本办法。

规则7

循环体内工作量最小化。

应仔细考虑循环体内的语句是否可以放在循环体之外，使循环体内工作量最小，从而提高程序的时间效率。

规则8

在多重循环中，应将最忙的循环放在最内层。

规则9

避免循环体内含判断语句，将与循环变量无关的判断语句移到循环体外。

目的是减少判断次数。循环体中的判断语句是否可以移到循环体外，要视程序的具体情况而言，一般情况，与循环变量无关的判断语句可以移到循环体外，而有关的则不可以。

规则10

中断和恢复

中断程序应该尽量短，应该在中断中进行标记，在主程序中处理。但实时性很高的程序段例外。

中断时应该保存所有涉及到的通用变量和寄存器，如A, PSW, DPTR等。

规则11

堆栈设置

堆栈对于程序非常重要，对于堆栈的设置要合理。堆栈太小，在嵌套调用和很容易溢出，造成系统故障;堆栈太大，浪费RAM资源。

为了节约堆栈资源，中断时要求不要保存太多资源，中断嵌套和程序嵌套层数不要太多，尽量不要超过5层。这就要求合理的划分功能模块。

规则12

看门狗

看门狗电路用于在单片机死机时自动复位。单片机需要定时向看门狗发送脉冲，俗称”喂狗”。喂狗不可太勤，这样看门狗没有起到作用;也不可太慢，这样容易造成单片机复位。正确的喂狗应该在主循环中进行，最好是建立一个独立的系统监控进程。不可以在定时中断中喂狗，应为单片机有时可能会在主循环中死掉。