软件开发作业流程标准规范.doc

软
件
开
发
流
程
规
范
V1.0

德联软件有限责任企业
编制人： 侯秀美 审核人：
年 8 月 19 日

目录
目录 0
一、概述 2
二、开发步骤规范 3
2.1 系统软硬件开发环境 3
2.2 系统架构（系统组成） 5
2.3 系统功效模块设计 6
2.4 系统功效开发步骤图 6
2.5 开发修改统计 7
三、开发代码规范 8
3.1 文件结构 8
3.1.1 文件信息申明 8
3.1.2 头文件结构 10
3.1.3 定义文件结构 11
3.1.4 头文件作用 12
3.1.5 目录结构 13
3.2 命名规则 13
3.2.1 共性标准 13
3.2.2 Windows变量命名规则 14
3.3 程序风格 16
3.3.1 空行 17
3.3.2 代码行 18
3.3.3 代码行内空格 19
3.3.4 对齐 20
3.3.5 长行拆分 22
3.3.6 修饰符位置 23
3.3.7 注释 23
3.4 函数设计 26
3.4.1 参数规则 26
3.4.2 返回值规则 27
3.4.3 函数内部实现规则 30
3.4.4 其它提议 32
3.4.5 使用断言 32
3.4.6 引用和指针比较 33
3.5 变量类型定义 35
四、软件测试规范 36
4.1 单元测试 36
4.2 系统测试 37
4.6 业务测试 38
4.7 验收测试 38
4.8 用户现场测试 38
五、软件版本管理 39
4.1版本管理必需性 39

一、概述
本文制订烟台开发区德联软件有限责任企业计算机软件开发规范文档。本规范目标是使企业软件开发项目阶段清楚、要求明确、任务具体、编写代码规范，使之规范化、系统化和工程化，向企业内从事软件开发工程师和管理人员提出一系列规范和要求，从而有利于开发过程控制和管理，提升所开发软件系统质量，缩短开发时间，降低开发和维护费用，以确保项目高质量、顺利进行。
本规范包含：开发步骤规范和开发代码规范等，开发步骤规范需要技术开发人员编写相关内容，期望每个技术人员形成习惯，如有新内容更新会立即通知大家，如有好规范要求也可通知编制人员立即更新。
本规范为烟台开发区德联软件有限责任企业内部材料，严禁其它商业应用。

二、开发步骤规范
接收开发任务，具体阅读软件技术规范或技术文档，如对技术文档有疑义或不清楚地方立即和项目总工或用户沟通，依据文档和沟通内容编写项目开发计划，必需包含但不限于系统软硬件开发环境、系统架构、系统功效模块设计、系统功效开发步骤图、开发修改统计。
2.1 系统软硬件开发环境
开发环境搭建，最好形成文档，便于以后一样工作使用。开发人员要明确系统开发拟采取数据库、操作系统、开发语言、开发工具、服务器等（具体到版本）。明确整个系统开发工作步骤，最少应该包含以下步骤。

2.2 系统架构（系统组成）
确定系统整体体系架构，各层次之间数据流连接，确定软件服务器硬件配置及用户硬件资源配置， 确定和用户软件平台统一协调。 开发人员在绘制架构图时给出基础框架，能反应出基础意义即可，能够直接用文字替换例子中图片。

图1 系统逻辑架构图举例

图2 物理架构图举例
2.3 系统功效模块设计
给出系统关键功效模块，每个模块所包含功效。

图3 图书管理系统模块计划图举例

2.4 系统功效开发步骤图
给出系统关键功效业务步骤图。

图4 系统功效业务步骤图举例

2.5 开发修改统计
1. 开发代码做好备份（能够在完成一个重大功效以后，或按时间周期性进行备份），以免因为不可抗力造成代码不可修复。
2.在每次重大修改以后要做好统计（改动具体细节），修改前版本要立即备份，能够方面随时还原系统。
修改日期
修改内容
是否备份
备注

三、开发代码规范
在研究项目团体协作开发情况下（这里团体协作也适合于应用项目标开发），编程时应该强调一个关键方面是程序易读性，在确保软件速度等性能指标能满足用户需求情况下，能让其它程序员轻易读懂你所编写程序。若研究项目小组全部开发人员全部遵照统一、鲜明一套编程风格，能够让协作者、后继者和自己一目了然，在很短时间内看清楚程序结构，了解设计思绪，大大提升代码可读性、可重用性、程序健壮性、可移植性、可维护性。
制订本编程规范目标是为了提升软件开发效率及所开发软件可维护性，提升软件质量。本规范由程序风格、命名规范、注释规范、程序健壮性、可移植性、错误处理和软件模块化规范等部分组成。
此规范以C/C++程序设计讨论。
3.1 文件结构
每个C++/C程序通常分为两个文件。一个文件用于保留程序申明（declaration），称为头文件。另一个文件用于保留程序实现（implementation），称为定义（definition）文件。
C++/C程序头文件以“.h”为后缀，C程序定义文件以“.c”为后缀，C++程序定义文件通常以“.cpp”为后缀（也有部分系统以“.cc”或“.cxx”为后缀）。
3.1.1 文件信息申明
文件信息申明在头文件和定义文件开头（参见示例3-1），关键内容有：
（1）       版权信息；
（2）       文件名称，项目代码，摘要，参考文件；
（3）       目前版本号，作者/修改者，完成日期；
（4）       版本历史信息；
（5）       关键函数描述。 
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
// Copyright (c) , DeLianSoftCompany YanTai
// All rights reserved.
//
// Filename ：filename.h
// Project Code ：The project code about this file
// Abstract ：Describe the content of this file summarily
// Reference ：......
//
// Version ：1.1
// Author ：the name of author(mender)
// Accomplished date ： September 2,
//
// Replaced version : 1.0
// Original Author : the name of original author(mender)
// Accomplished date : September 10,
//
// Main functions ：
// Function 1 Return code Function name(Parameter Explain)
// Function 2 Return code Function name(Parameter Explain)
// ...
// Function n Return code Function name(Parameter Explain)
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

示例3-1 文件信息申明
☆       【规则3.1-1】 文件信息申明以两行斜杠开始，以两行斜杠结束，每一行全部以两个斜杠开始；
☆       【规则3.1-2】 文件信息申明包含五个部分，各部分之间以一空行间隔；
☆        【规则3.1-3】 在关键函数部分描述了文件所包含关键函数申明信息，假如是头文件，这一部分是能够省略。
3.1.2 头文件结构
头文件由三部分内容组成：
(1)    头文件开头处文件信息申明(参见示例3-1)；
(2)    预处理块；
(3)    函数和类结构申明等。
假设头文件名称为 filesystem.h，头文件结构参见示例3-2。
☆       【规则3.2-1】 为了预防头文件被反复引用，应该用ifndef/define/endif结构产生预处理块；“#ifndef”或“#define”后以TAB键替换SPACE键做空格；假如头文件名称是由多个单词组成，则各单词间以下划线“_”连接，比如有头文件名称为“filesystem.h”，则定义以下：“#ifndef _FILE_SYSTEM_H_”；
☆       【规则3.2-2】 用 #include< filename.h> 格式来引用标准库头文件(编译器将从标准库目录开始搜索)；
☆       【规则3.2-3】 用 #include “filename.h” 格式来引用非标准库头文件(编译器将从用户工作目录开始搜索)；
☆       【提议3.2-1】 头文件中只存放“申明”而不存放“定义”；
☆       【提议3.2-1】 头文件中应包含全部定义文件所定义函数申明，假如一个头文件对应多个定义文件，则不一样定义文件内实现函数要分开申明，并作注释以解释所申明函数隶属于那一个定义文件；
☆       【提议3.2-3】 宏定义和函数申明分离，在两个头文件中定义，假如没有类组员函数，能够将类和结构定义和函数申明分离，也就是说一个头文件专用于宏定义，一个头文件专用于类和结构定义，一个头文件专用于函数申明；
☆       【提议3.2-4】 在C++ 语法中，类组员函数能够在申明同时被定义，而且自动成为内联函数。这即使会带来书写上方便，但却造成了风格不一致，弊大于利。提议将组员函数定义和申明分开，不管该函数体有多么小。
头文件结构以下：
//文件信息申明见示例3-1，此处省略。 
#ifndef _FILE_SYSTEM_H_ //avoid referencing the file filesystem.h repeat
#define _FILE_SYSTEM_H_

#include <math.h> //reference standard head file
…
#include “myheader.h” //reference non-standard head file
…
void Function1(…); //global function declare
…
class CBox //class structure decalre
{
…
};
#endif
示例3-2 C++/C头文件结构

3.1.3 定义文件结构
定义文件有三部分内容：
(1)    定义文件开头处文件信息申明(参见示例3-1)；
(2)    对部分头文件引用；
(3)    程序实现体（包含数据和代码）。
假设定义文件名称为 filesystem.c，定义文件结构参见示例3-3。
//文件信息申明见示例3-1，此处省略。

#include “filesystem.h” //reference a head file
…

//global function realization
void Function1(…)
{
…
}

//class member function realization
void CBox::Draw(…)
{
…
}
示例3-3 C++/C定义文件结构
3.1.4 头文件作用
早期编程语言如Basic、Fortran没有头文件概念，C++/C语言初学者即使会用使用头文件，但常常不明其理。这里对头文件作用略作解释：
（1） 经过头文件来调用库功效。在很多场所，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制库即可。用户只需要根据头文件中接口申明来调用库功效，而无须关心接口怎么实现。编译器会从库中提取对应代码；
（2） 头文件能加强类型安全检验。假如某个接口被实现或被使用时，其方法和头文件中申明不一致，编译器就会指犯错误，这一简单规则能大大减轻程序员调试、改错负担。
3.1.5 目录结构
假如一个软件头文件数目比较多（如超出十个），通常应将头文件和定义文件分别保留于不一样目录，方便于维护。
比如可将头文件保留于include目录，将定义文件保留于source目录（能够是多级目录）。
假如一些头文件是私有，它不会被用户程序直接引用，则没有必需公开其“申明”。为了加强信息隐藏，这些私有头文件能够和定义文件存放于同一个目录。
3.2 命名规则
比较著名命名规则当推“匈牙利” 命名法，该命名规则关键思想是“在变量和函数名中加入前缀以促进大家对程序了解”。比如全部字符变量均以ch为前缀，若是指针变量则追加前缀p。假如一个变量由ppch开头，则表明它是指向字符指针指针。
“匈牙利”法最大缺点是烦琐，比如
int i, j, k;
float x, y, z;
倘若采取“匈牙利”命名规则，则应该写成
int iI, iJ, ik; // 前缀 i表示int类型
float fX, fY, fZ; // 前缀 f表示float类型
如此烦琐程序会让绝大多数程序员无法忍受。
总说来，没有一个命名规则能够让全部程序员赞同，且命名规则对软件产品而言并不是“成败悠关”事，而且在不一样平台和不一样环境下编写程序所应遵照规则也不尽相同，所以我们只是追求制订一个令大多数项目组员满意命名规则，并在项目中落实实施。
3.2.1 共性标准
本节叙述共性规则是被大多数程序员采纳，我们应该在遵照这些共性规则前提下，再扩充特定规则，如3.2.2节

☆       【规则3.2.1-1】 标识符应该直观且能够拼读，可望文知意，无须进行“解码”；
☆       【规则3.2.1-2】 标识符长度应该符合“min-length && max-information”标准；
☆       【规则3.2.1-3】 命名规则尽可能和所采取操作系统或开发工具风格保持一致；
☆       【规则3.2.1-4】 程序中不要出现仅靠大小写区分相同标识符。
☆       【规则3.2.1-5】 程序中不要出现标识符完全相同局部变量和全局变量，尽管二者作用域不一样而不会发生语法错误，但会使人误解；
☆       【规则3.2.1-6】 变量名字应该使用“名词”或“形容词＋名词”；
☆       【规则3.2.1-7】 全局函数名字应该使用“动词”或“动词＋名词”(动宾词组)；
☆       【规则3.2.1-8】 用正确反义词组命名含有互斥意义变量或相反动作函数等；
☆       【提议3.2.1-9】 尽可能避免名字中出现数字编号，如Value1,Value2等，除非逻辑上确实需要编号；
注：
3.2.1              标识符最好采取英文单词或其组合，便于记忆和阅读，切忌使用汉语拼音来命名，程序中英文单词通常不要太复杂，用词应该正确，比如不要把CurrentValue写成NowValue；
3.2.2              标示符长度应该以最小长度实现最多信息，通常来说，长名字能愈加好地表示含义，但并非长变量名就一定要比短变量名要好，另外单字符名字也是有用，常见如i,j,k,m,n,x,y,z等，它们通常可用作函数内局部变量；
3.2.3              不一样操作系统程序设计风格是不一样，比如Windows应用程序标识符通常采取“大小写”混排方法，如AddChild，而Unix应用程序标识符通常采取“小写加下划线”方法，如add_child，别把这两类风格混在一起使用；
3.2.2 Windows变量命名规则
☆       【规则3.2.2-1】 变量命名规则要求采取“匈牙利法则”，即开头字母用变量类型，其它部分用变量英文意思或其英文意思缩写，尽可能避免采取汉字拼音，要求单词第一个字母大写；
即：变量名＝变量类型＋变量英文意思(或缩写)
变量类型请参见附表1－变量类型表；
☆       【规则3.2.2-2】 类名和函数名用大写字母开头单词组合而成；对struct、union、class变量命名要求定义类型用大写，结构采取S开头，联合体采取U开头，类采取C开头；
比如：
struct SPoint
{
int m_nX;
int m_nY;
};
union URecordLen
{
BYTE m_byRecordNum;
BYTE m_byRecordLen;
}
class CNode
{
//类组员变量或组员函数
};
☆     【规则3.2.2-3】 指针变量命名基础标准为：
一重指针变量基础标准为：
变量名＝ “p”＋变量类型前缀＋命名
对多重指针变量基础标准为：
二重指针：
变量名＝“pp”＋变量类型前缀＋命名
三重指针：
变量名＝“ppp”＋变量类型前缀＋命名
......
比如一个short*型变量应该表示为pnStart；
☆     【规则3.2.2-4】 全局变量用g_开头；比如一个全局长型变量定义为g_lFileNum，
即：变量名＝g_＋变量类型＋变量英文意思(或缩写)；
☆     【规则3.2.2-5】 静态变量采取s_开头；比如一个静态指针变量定义为s_plPrevInst，
即：变量名＝s_＋变量类型＋变量英文意思(或缩写)；
☆     【规则3.2.2-6】 类组员变量采取m_开头；比如一个长型组员变量定义为m_lCount，
即：变量名＝m_＋变量类型＋变量英文意思(或缩写)；
☆       【规则3.2.2-7】 对const变量要求在变量命名规则前加入c_(若作为函数输入参数，能够不加)，
即：变量名＝c_＋变量命名规则，比如：
const char* c_szFileName；
☆       【规则3.2.2-8】 对枚举类型(enum)中变量，要求用枚举变量或其缩写做前缀，且用下划线隔离变量名，全部枚举类型全部要用大写，比如：
enum EMDAYS
{
EMDAYS_MONDAY;
EMDAYS_TUESDAY;
......
}；
☆       【规则3.2.2-9】 对常量(包含错误编码)命名，要求常量名用大写，常量名用英文意思表示其意思，用下划线分割单词，比如：
#define CM_7816_OK 0x9000；
☆       【规则3.2.2-10】 为了预防某一软件库中部分标识符和其它软件库中冲突，能够为多种标识符加上能反应软件性质前缀。比如三维图形标准OpenGL全部库函数均以gl开头，全部常量（或宏定义）均以GL开头。
3.3 程序风格
程序风格即使不会影响程序功效，但会影响程序可读性，追求清楚、美观，是程序风格关键组成原因。
3.3.1 空行
空行起着分隔程序段落作用。空行得体（不过多也不过少）将使程序布局愈加清楚。空行不会浪费内存，即使打印含有空行程序是会多消耗部分纸张，不过值得。

☆       【规则3.3.1-1】 在每个类申明以后、每个函数定义结束以后全部要加空行。参见示例3.3.1(a)；
☆       【规则3.3.1-2】 在一个函数体内，逻揖上亲密相关语句之间不加空行，其它地方应加空行分隔。参见示例3.3.1(b)；

// blank line
void Function1(…)
{
…
}
// blank line
void Function2(…)
{
…
}
// blank line
void Function3(…)
{
…
}

// blank line
while (condition)
{
statement1;
// blank line
if (condition)
{
statement2;
}
else
{
statement3;
}
// blank line
statement4;
}
示例3.3.1(a) 函数之间空行 示例3.3.1(b) 函数内部空行

3.3.2 代码行
☆       【规则3.3.2-1】 一行代码只做一件事情，如只定义一个变量，或只写一条语句,这么代码轻易阅读，而且方便于写注释；
☆       【规则3.3.2-2】 if、for、while、do等语句自占一行，实施语句不得紧跟其后，不管实施语句有多少全部要加{}，这么能够预防书写失误；
☆       【规则3.3.2-3】 if、for、while、do等语句“{”要单独占用一行；
☆       【提议3.3.2-1】 全部函数内变量全部在函数开始处定义；
☆       【提议3.3.2-2】 尽可能在定义变量同时初始化该变量(就近标准)，假如变量引用处和其定义处相隔比较远，变量初始化很轻易被忘记。假如引用了未被初始化变量，可能会造成程序错误，本提议能够降低隐患。

示例3.3.2(a)为风格良好代码行，示例3.3.2(b)为风格不良代码行。

int nWidth; // width
int nHeight; // height
int nDepth; // depth

int nWidth,nHight,nDepth;//width,height,depth

x = a + b;
y = c + d;
z = e + f;
X ＝ a + b; y = c + d; z = e + f;

if (nWidth < nHight)
{
DoSomething();
}
if (nWidth < nHight) DoSomething();
for (initialization; condition; update)
{
DoSomething();
}
// blank line
Other();

for (initialization; condition; update)
DoSomething();
Other();

示例3.3.2(a) 风格良好代码行 示例3.3.2(b) 风格不良代码行
3.3.3 代码行内空格
☆       【规则3.3.3-1】 关键字以后要留空格，象const、virtual、inline、case 等关键字以后最少要留一个空格，不然无法辨析关键字，象if、for、while等关键字以后应留一个空格再跟左括号‘（’，以突出关键字；
☆       【规则3.3.3-2】 函数名以后不要留空格，紧跟左括号‘（’，以和关键字区分；
☆       【规则3.3.3-3】 ‘（’向后紧跟，‘）’、‘，’、‘;’向前紧跟，紧跟处不留空格；
☆       【规则3.3.3-4】 ‘，’以后要留空格，如Function(x, y, z)，假如‘;’不是一行结束符号，其后要留空格，如for (initialization; condition; update)；
☆       【规则3.3.3-5】 赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符前后应该加空格；
☆       【规则3.3.3-6】 一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格；
☆       【规则3.3.3-7】 象“［］”、“.”、“->”这类操作符前后不加空格；
☆       【提议3.3.3-1】 对于表示式比较长for语句和if语句，为了紧凑起见能够合适地去掉部分空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))

void Func1(int x, int y, int z); // favorable style
void Func1 (int x,int y,int z); // ill style
if (year >= ) // favorable style
if(year>=) // ill style
if ((a>=b) && (c<=d)) // favorable style
if(a>=b&&c<=d) // ill style
for (i=0; i<10; i++) // favorable style
for(i=0;i<10;i++) // ill style
for (i = 0; I < 10; i ++) // favorable style
x = a < b ? a : b; // favorable style
x=a<b?a:b; // ill style
int *x = &y; // favorable style
int * x = & y; // ill style
array[5] = 0; // Do not use array [ 5 ] = 0;
a.Function(); // Do not use a . Function();
b->Function(); // Do not use b -> Function();

示例3.3.3 代码行内空格 
3.3.4 对齐
☆       【规则3.3.4-1】 程序分界符‘{’和‘}’应独占一行而且在同一列，同时和引用它们语句左对齐；
☆       【规则3.3.4-2】 { }之内代码块在‘{’右边数格处左对齐；
☆       【规则3.3.4.3】 代码对齐采取TAB键而不采取空格键对齐，通常TAB键设置为向后空4个空格。
 示例3.3.4(a)为风格良好对齐，示例3.3.4(b)为风格不良对齐。

void Function(int x)
{
… // program code
}

void Function(int x){
… // program code
}

if (condition)
{
… // program code
}
else
{
… // program code
}
if (condition){
… // program code
}
else {
… // program code
}
for (initialization; condition; update)
{
… // program code
}
for (initialization; condition; update){
… // program code
}
While (condition)
{
… // program code
}
while (condition){
… // program code
}
假如出现嵌套｛｝，则使用缩进对齐，如：
{
…
{
…
}
…
}

示例3.3.4(a) 风格良好对齐 示例3.3.4(b) 风格不良对齐
3.3.5 长行拆分
☆       【规则3.3.5-1】 代码行最大长度宜控制在70至80个字符以内；
☆       【规则3.3.5-2】 长表示式要在低优先级操作符处拆分成新行，操作符放在新行之首（方便突出操作符），拆分出新行要进行合适缩进，使排版整齐，语句可读。
 if ((very_longer_variable1 >= very_longer_variable12)
&& (very_longer_variable3 <= very_longer_variable14)
&& (very_longer_variable5 <= very_longer_variable16))
{
DoSomething();
}
virtual CMatrix CMultiplyMatrix (CMatrix leftMatrix,
CMatrix rightMatrix);

for (very_longer_initialization;
very_longer_condition;
very_longer_update)
{
DoSomething();
}
示例3.3.5 长行拆分
3.3.6 修饰符位置
修饰符 * 和 ＆ 应该靠近数据类型还是该靠近变量名，是个有争议活题，若将修饰符 * 靠近数据类型，比如：int* x; 从语义上讲此写法比较直观，即x是int 类型指针，上述写法弊端是轻易引发误解，比如：int* x, y; 此处y轻易被误解为指针变量。即使将x和y分行定义能够避免误解，但并不是人人全部愿意这么做。
☆       【规则3.3.6-1】 应该将修饰符 * 和 ＆ 紧靠变量名；
3.3.7 注释
C语言注释符为“/*…*/”。C++语言中，程序块注释常采取“/*…*/”，行注释通常采取“//…”。注释通常见于：
（1）版本、版权申明；
（2）函数接口说明；
（3）关键代码行或段落提醒。
即使注释有利于了解代码，但注意不可过多地使用注释。参见示例3.3.7。 
☆       【规则3.3.7-1】 注释是对代码“提醒”，而不是文档，程序中注释不可喧宾夺主，注释太多了会让人眼花缭乱，注释花样要少；
☆       【规则3.3.7-2】 假如代码原来就是清楚，则无须加注释；比如
i++; // i 加 1，多出注释
☆       【规则3.3.7-3】 边写代码边注释，修改代码同时修改对应注释，以确保注释和代码一致性，不再有用注释要删除；
☆       【规则3.3.7-4】 注释应该正确、易懂，预防注释有二义性，错误注释不仅无益反而有害；
☆       【规则3.3.7-5】 尽可能避免在注释中使用缩写，尤其是不常见缩写；
☆       【规则3.3.7-6】 注释位置应和被描述代码相邻，能够放在代码上方或右方，不可放在下方；
☆       【规则3.3.7-8】 现代码比较长，尤其是有多重嵌套时，应该在部分段落结束处加注释，便于阅读；
☆       【提议3.3.7-9】 对于多行代码注释，尽可能不采取“/*...*/”，而采取多行“//”注释，这么即使麻烦，不过在做屏蔽调试时不用查找配正确“/*...*/”。

 ////////////////////////////////////////////////////////////////////
// Function capacity：
// Parameter declare：
// Return value ：
////////////////////////////////////////////////////////////////////
void Function(float x, float y, float z)
{
…
}
 if (…)
{
…
while (…)
{
…
} // end of while
…
} // end of if
示例3.3.7 程序注释
3.7.1 文件头注释
文件头注释请参见3.1，文件头注释是以两行斜杠开始，以两行斜杠结束(以区分于函数注释)。
3.7.2 函数头注释
通常说来每个函数全部应该做具体注释，函数头注释是以一行斜杠开始，以一行斜杠结束，注释内容包含“功效”，“参数”，“返回值”，“设计思想”，“调用函数”，“日期”，“修改统计”等多个方面，函数头注释格式以下：

//////////////////////////////////////////////////////////////////////////////////////////////
// Function capacity ： Describe the function capacity
// Parameter declare ：
// parameter 1： Describe the function of parameter ( input/output parameter )
// parameter 2： Describe the function of parameter ( input/output parameter )
// ......
// Return value ： Describe the possible return value
// Designed idea ： Describe designed idea about the function
// Author ：
// Creation date ： Creation date(YY-MM-DD)
// Transferred function： List the sub-function in the function
// Modification record：
// (一)Mender 1： Modified date： modified content
///////////////////////////////