软件设计规范

工作文件

文件名称：软件设计规范

文件编号：版号：A

编制：日期：

审核：日期：

批准：日期：

受控状态：

生效日期:

分发号:

工作文件文件编号：

软件设计规范版号/修改状态：A/0

1目的

2本规范是对项目软件设计的一份规范性文件，对软件设计过程中的活动进行总体规

范，以有效保证软件产品的质量。

3范围

本规范适用于公司研制的全部软件产品。

4设计流程

a）软件设计流程按照《软件设计和开发控制程序》中规定执行，软件开发过程可包

括以下活动：

b）需求分析；

c）软件开发；

d）软件测试；

e）项目验收；

0客服支持。

5前期准备

6软件开发人员对系统开发前期进行充分的用户调研、需求分析和系统体系结构的设

计准备工作。软件开发人员以及业务需求人员共同组建项目组，一名或两名项目经

理负责监控项目的整体实施，共同参与系统的全面设计、开发，并针对业务提出进

一步开发需求，开展软件用户化工作，制定二次开发方案，参与设计业务系统与其

它软件的接口。

7实施过程

整个开发过程将经历获取需求、需求分析、系统设计、编码、测试等阶段。

5.1获取需求

a）软件在进入正式开发之前，提供准确的书面《需求规格说明书》其中包括：

b）对现有系统的分析。

c）待开发系统的详细需求。

d）功能需求，使用范围，业务流程，用户界面，输出要求，故障处理。

网络环境，硬件环境，软件环境，与其他系统的关系，安全与保密。

第1页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

技术可行性分析，经济可行性分析，人员可行性分析，影响待开发系统的主要因

素。

软件项目分为专用软件和通用软件两大类。

5.2对于专用软件，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清

楚用户理想的产品究竟是什么样子，这里最好就采用原型化的方法作出一个简单的框架

给用户看。

5.3对于通用软件，在开发之前必须做一定的市场调查工作，一方面是从经济效益考

虑，调查产品的潜在市场有多大，一方面是从技术的角度，了解清楚潜在用户对软件的

各种技术上的要求，另一方面是确定软件的定位，即我们软件具体是为哪一些用户群体

服务的。然后对该群体用户现有硬件配置，软件配置，网络使用情况，数据库使用情况,

计算机熟悉程度做一定的调研，根据调查的统计结果决定即将开发的软件的一些技术指

标。

5.4需求分析

开发人员构思、确立系统目标、划分业务领域、现行业务分析、建立业务模型、信

息需求分析、用户视图规范化、数据元素标准化与一致性控制等。

在项目组和用户充分交互、理解的基础上，提出系统的技术构架，对系统功能、性能等

主要指标作描述，对实现方法项目实施人员应有一个比较清晰的轮廓及整体设计思路,

对有疑问的地方及时与业务需求人员进行沟通交流，最终达成共识。

综合对该用户群体现有硬件配置，软件配置，网络使用情况，数据库使用情况，计

算机熟悉程度做一定的调研，根据调杳的统计结果决定即将开发的一些软件适用指标。

这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。

用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面

包含了很多操作方面的流程和条件。

数据词典是指明数据逻辑关系并加以整理，完成了数据词典，数据库的设计就完成

了一半多。

用户操作手册是指明了操作流程的说明书。

5.5软件开发

第2页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

5.3.1系统结构建立

确定软件服务器的硬件配置及用户硬件资源配置。

确定用户软件平台的统一协调。

5.3.2软件设计

5.3.3软件设计阶段的工作包括对模块进行必要的修改，同时可能需要对某些结构做一

些修改，确定界面定义、月户服务层、业务逻辑层、数据库服务层和具体数据库，确定

软件开发工具。这一阶段还将完成更详细的功能和业务需求调研，制作系统中最符合用

户需要的文档。

5.3.4根据应用系统对安全的要求，同步进行安全保密设计。

5.3.5软件编码

5.3.5.1确定软件的界面风格、使用功能、编程语言、数据库结构和具体数据等工作，并

开始进入程序编写阶段。

5.3.5.2开发人员进入设置和编码工作之后，应先确定编码的风格在开发过程中保持

一致，工作过程中如发现前面分析或设计阶段的某些错误，应返回到前面的

阶段进行必要的修改，同时主要开发人员之间应相互紧密配合。编码语言除用

户特别要求外应尽量使用常用语言，详细语言编码规范参考《C++编码规范》

（附件A）和《C#编码规范》（附件B）。

5.3.5.3代码规范

有些不易理解的变量或函数应作注释，难懂的代码要有注解，在文件的开始处有该

文件的用途描述。一定要保持注释的一致性。

代码组织要清晰，{,},（,）,if,else,do,while,for,case等要对应整齐，少用空格，缩进全部

用Tab键。变量的定义要集中，函数间要有空行分开，一个程序中的空行数目最好占

8%-16%o多态函数和功能相近的函数集中放在一起,

代码应该简洁、清楚并讲述了所发生的一切。某些公用代码要注意多平台易移植，最

好使用标准C。

5.3.5.4代码的重用要仔细，要将相关的代码也拷贝过来，注意那段代码是否适合需

求的应用场合。

第3页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

5.3.5.5删掉从来没有用过的函数或变量，大篇幅注释掉的代码行也应删除，以免使

程序混乱难读。

5.3.5.6工程文件组织规范

一个工程往往包含很多很多文件资源文件等），向工程中加入

文件或删除工程中的文件要慎重，避免把工程损坏。工程中不起作用的文件或类应删除,

工程目录下的非工程文件也应该移走，保持工程的清洁，避免混淆难于管理。工程文件

如果很多，应归类。

在VC环境下，建议将常用的头文件全部放入sidafx.h中，而在每个cpp开始处嵌入

stdafx.ho避免头文件的交叉引用，如果有严重的交叉引用，适当使用类的声明。

将独立性比较强的模块抽出来，做成DLL,控件或COM组件，该模块可单独编写

和测试，也增强了其可重用性。

一个比较大的工程应留有一定的消息接口或插件接口等。

工程的版本控制要严格，版本格式为xx.xx.xx,必要时使用Build次数或日期。高版

本尽量兼容低版本的用法、数据或协议。

工程的编译宏定义和工程参数设置应正确，每作一个新工程时应检查工程参数是否

正确。

建议字节对齐方式为1字节对齐。

5.3.5.7工程文件应经常备份，备份时注明备份日期和主要增加的功能。

5.3.5.8类组织规范

类一般有两个文件，一个头文件，一个实现体CPPo

5.3.5.9类力求封装好，严格区分public,private,protect等作用域，如果一个函数与本

类有莫大的关系，可以作为该类的静态成员函数，不用或少用友元函数等破

坏类封装性的方法和技巧。如果一些结构或宏仅与本类有关，可在类头文件

中定义。

5.3.5.10类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋

NULL,析构时DEL_EMPTY它，以免内存泄露。

5.3.5.11用户界面规范

第4页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

有四大类型的用户界面：对话框、单文档界面、多文档界面、其它界面。

对话框要易用且简洁，字体和控件的组织搭配要得体，能简单不复杂，各控件的焦

点、Tab顺序等要讲究，视应用场合要适当支持键盘。在简洁易用的前提下，力求个性

化，设计得更加友好。程序各对话框的风格要保持一致。

单文档和多文档界面的程序功能强，也便于扩充和管理。其中菜单、工具栏、状态

栏等设计要有特色。菜单按一定的分类弹出，必要时设计成多套菜单，在重要的窗口或

区域应能弹出右键，实现常见操作。工具栏上放最常用的操作按钮，必要时动态更换按

钮。状态栏显示足够多的有用信息。

5.6消息主控在Mainframe中，单文档的主控也可在View中，所有的对话框的弹出或

非模态对话框的控制都在主控窗口中完成，具体的数据处理放在单独的文件中或设计成

类。在App类中实现Ini读写，各数据对象的定义和析构，全局变量的赋值和初始计算,

存盘退出等。各视图的OnDraw和GDI画图尽量使用内存位图的方式，以免闪烁。

5.7其它还有ATL,控制台，嵌入式程序界面等，也有作为其它容器如IE中的插件等,

此类程序可能不用MFC,而采用COM组件等方法实现。

5.8软件测试

5.9测试时系统投入使用前最关键的一个步骤，由开发人员之间、业务需求人员交叉测

试或由软件测试工程师测试。开发人员将对在测试过程中发现的问题提出可行建议进行

改进。测试方法、测试类型及测试结果判断规范参考《软件测试规范》。

5.10项目验收

5.5.1建设工程包括多个方面的工作和任务，每一项任务的完成、每一个文档的提交、

每一个设备、软件或应用系统的交付，都有相应的完成标志和测试、评估和验收

标准。对于系统、网络和应用这种重大的工作里程碑事件，测试验收工径更为严

谨和充分，计划更为周密。

5.5.2按照系统集成服务的程序和行业惯例，整个项目实施过程中要对不同的交付项目

进行如下各类测试和验收中的一种或几种，具体进行哪种或哪些测试验收工作依

交付项目的性质不同而不同。

5.5.3审议确认

第5页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

5.5.4这是一种采用对交付件内容进行阅读、讲解、评议、问题与回答的形式进行评审,

并作出接受或拒绝决定的方法。对于交付的项目管理文档、设计文档、测试报告、

技术资料等交付项目，通常采用这种方法。

5.5.5安装测试

5.5.6采用标准的测试程序（如硬件设备开机自检）和操作方法，对交付件进行测试的方

法。通常用于对硬件设备和系统软件的验收。

5.5.7初始安装测试

5.5.8类似于安装测试，通常用于对最终提交结果进行安装测试。典型的情况是系统软

件的初始安装测试，此时安装的是用于进行设计开发的平台或工具，而不是直接

提交客户作生产目的。

5.5.9用户验收测试

用户验收测试是用户根据自己的业务处理要求，在实际系统上进行的类似于系统集

成测试的过程。这种测试的目的是检验交付系统是否达到设计要求，是否可以投入业务

运行。与系统集成测试的不同在于，用户验收测试更加着重从业务功能方面的测试，时

间也相对短。

验收测试计划确立了对系统进行测试验收的方式和标准。公司将指导用户制订验收

测试计戈U（在验收测试开始前两周）。

a）测试计划将包括：

b）测试目标

c）角色和职责

d）测试环境

e）要测试的功能和外观特征

0测试手段

g）测试案例及预期结果

5.5.10当所有功能和外观特征经测试达到验收测试计划所说明的完成标志，客户将接收

该系统。在测试过程中，任一项没有达到完成标志，开发商将负责修正然后再进

行测试。某些测试失败可能由于对项目实施目标的误解而导致，对这些误解进行

第6页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

分析。如果是开发商的责任，将做必要的修正并再进行测试。

5.5.11人员培训

5.5.12对用户人员进行技术培训是工程成功的重要因素，是整个项目能否顺利实施的重

要保证。针对设备或软件系统的业务和技术特点及要求，我们将提供必要的技术

培训，并可就客户的其它具体要求提供其它方面的培训。

5.5.13资料文档

a）为保证系统的建设和正常运行，我们可以提供如下设计类、计划类、测试类资

料和文档，各项目根据自身情况进行剪切。

b）软件需求规格说明

c）系统设计文档

d）数据库设计文档

e）软件开发计划

0开发计划

g）软件配置项测试计划

h）测试大纲

1）测试报告

j）验收报告

k）用户手册

5.11客服支持

5.6.1培训目标

5.6.2在实施项目的过程中，使相关操作人员理解软件的基本原理和实际运用，使他们

对整套业务软件的具体性能，操作步骤以及具体要求，有一个更深层次的认识,

并能在计算机管理下对其业务软件流程熟练操作使用。

5.6.3再开发人员共同接受软件开发方全面、系统的培训I,保证能够在后期推广中独挡

一面完成推广及软件升级任务。

5.6.4培训计划

5.6.5项目组有义务对用户提供及时、有效、全面的培训，并在项目实施过程中充分重

第7页共66页

工作文件文件编号:

软件设计规范版号/修改状态：A/0

视对用户方的技术转移，并提前制订有效可行的培训计划。

5.6.6考核标准

以实际操作方式测试用户对软件系统流程的操作使用能力。

第8页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

附录AC++编码规范

1文件结构

1.1文件头注释

所有C++的源文件均必须包含一个规范的文件头，文件头包含了该文件的名称、功能概

述、作者、版权和版本历史信息等内容。标准文件头的格式为：

/*!@file

*****木木***木*求*************木*木*******************求***长**木*求*木木*****求*木**木木木*木*太木*

<PRE>

模块名：<文件所属的模块名称〉

文件名：〈文件名〉

相关文件：〈与此文件相关的其它文件〉

文件实现功能：〈描述该文件实现的主要功能》

作者：〈作者部门和姓名,

版本：〈当前版本号,

多线程安全性：〈是/否>L说明］

异常时安全性：〈是/否>L说明］

备注：〈其它说明,

修改记录：

日期版本修改人修改内容

YYYY/MM/DDX.Y<作者或修改者名〉〈修改内容〉

</PRE>

********************************************************:§:**********:§:***********/

如果该文件有其它需要说明的地方，还可以专门为此扩展一节，节与节之间用长度

为8()的“=”带分割:

/*!@filc

第9页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

****************************************************«*************************K*

＜PRE＞

模块名：〈文件所属的模块名称〉

文件名：〈文件名〉

相关文件：〈与此文件相关的其它文件,

文件实现功能：〈描述该文件实现的主要功能〉

作者：〈作者部门和姓名,

版本：v当前版本号》

多线程安全性：v是/否＞[,说明]

异常时安全性：＜是/否＞[,说明]

备注：〈其它说明〉

修改记录：

日期版本修改人修改内容

YYYY/MM/DDX.Y〈作考或修改者名〉〈修改内容,

</PRE>

****************************************************k***************************

*项目1

-项目1.1

-项目1.2

*项目2

第10页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

-项目2.1

-项目2.2

每行注释的长度都不应该超过80个半角字符。还要注意缩进和对齐，以利阅读。

注意：将多线程和异常时安全性描述放在文件头，而不是类或者函数注释中，是为了体

现以下设计思想：同一个模块中的界面，其各方面的操作方式和使用风格应该尽量

保持一致。

a）1.2头文件

头文件通常由以下几部分组成：

b）文件头注释

c）每个头文件，无论是内部的还是外部的，都应该由一个规范的文件头注释作为

开始。

d）预处理块

e）为了防止头义件被歪.复引用，应当用ifndef/defme/endif结构产生预处理块。

f）函数和类/结构的声明等

声明模块的接口。

g）需要包含的内联函数定义文件（如果有的话）

如果类中的内联函数较多，或者一个头文件中包含多个类的定义（不推荐），可以

将所有内联函数定义放入一个单独的内联函数定义文件中，并在类声明之后用

/include”指令把它包含进来。

a）头文件的编码规贝！：

b）引用文件的格式

用include<filename.h>格式来引用标准库和系统库的头文件（编译器将从标准库

目录开始搜索）。

用include"filename.h"格式来引用当前工程中的头文件（编译器将从该文件所在

第11页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

目录开始搜索）。

C）分割多组接口（如果有的话）

如果在一个头件中定义了多个类或者多组接口（不推荐），为了便于浏览，应该在

每个类/每组接口间使用分割带把它们相互分开。

关于头文件的完整例子，请参见：头文件例子

1.3内联函数定义文件

如上所述，在内联函数较多的情况下，为了避免头文件过长、版面混乱，可以将所有

的内联函数定义移到一个单独的文件中去，然后再用指慎比加指令将它包含到类声明的

后面。这样的文件称为一个内联函数定义文件。

按照惯例，应该将这个文件命名为afilename.inr,,其中wfilenamew与相应的头文

件和实现文件相同。

a）内联函数定义文件由以下儿部分组成：

b）文件头注释

每内联函数定义文件都应该由一个规范的文件头注释作为开始。

c）内联函数定义

内联函数的实现体。

a）内联函数定义文件的编码规则：

b）分割多组接口（如果有的话）

c）如果在一个内联函数定义文件中定义了多个类或者多组接口的内联函数（不推

荐），必须在每个类/每组接口间使用分割带把它们相互分开。

文件组成中为什么没有预处理块？

与头文件不同，内联函数定义文件通常不需要定义预处理块，这是因为他们总是被包含

在与其相应的头文件预处理块内。

1.4实现文件

a）实现文件包含所有数据和代码的实现体。实现文件的格式为：

b）文件头注释

每个实现文件都应该由一个规范的文件头注释作为开始

第12页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

c）对配套头文件的引用

引用声明了此文件实现的类、函数及数据的头文件

d）对一些仅用于实现的头文件的引用（如果有的话）

e）将仅与实现相关的接口包含在实现文件里（而不是头文件中）是一个非常好的

编程习惯。这样可以有效地屏蔽不应该暴露的实现细节，将实现改变对其它模

块的影响降低到最少。

f）程序的实现体

数据和函数的定义

实现文件的编码规则：

分割每个部分：在本地（静态）定义和外部定义问，以及不同按口或不同类的实现之间,

应使用分割带相互分开。

1.5文件的组织结构

由于项目性质、规模上存在着差异，不同项目间的文件组织形式差别很大。但文件、

目录组织的基本原则应当是一致的：使外部接口与内部实现尽量分离；尽可能清晰地表

达软件的层次结构。

为此提供两组典型项目的文件组织结构范例作为参考：

1.5.1功能模块/库的文件组织形式

显而易见，编写功能模块和库的主要目的是为其它模块提供•套完成特定功能的API,

这类项目的文件组织结构通常如下图所示：

LibSample

Ocontrib

；0doc

Oinclude

:曰lib

1makefile

Osrc

■"Otest

其中:

Contrib:当前项目所依赖的所有第三方软件，可以按类别分设子目录。

Doc:项目文档

Include;声明外部接口的所有头文件和内联定义文件。

第13页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

Lib：编译好的二进制库文件，可以按编译器、平台分设子目录。

Makefile:用于编译项目的makefile文件和project文件等。可以按编译器、平台分

设子目录。

Src:所有实现文件和声明内部接口的头文件、内联定义文件。可.按功能划分；支持编译

器、平台等类别分设子目录。

Test:存放测试用代码的目录。

1.5.2应用程序的文件组织形式

与功能模块不同，应用程序是一个交付给最终用于使用的、可以独立运行并提供完整功

能的软件产品，它通常不提供编程接口，应用程序的典型文件组织形式如下图所示：

&

•

•AppSample

)

：

；contrib

•

一

…

•doc

…

.-

.…

.•makefile

…

.-

..

..setup

.-

.…

.•src

…

.-

.

Contrib:当前项目所依赖的所有第三方软件，可以按类别分设子目录。

Doc:项目文档

Makefile:用于编译项目的makefile义件和project义件等。可以按编译器、平台分

设子目录。

Setup：安装程序，以及制作安装程序所需要的项目文件和角本。

Src:所有源文件。可按功能划分；支持编译器、平台等类别分设子目录。

Test:存放测试用代码的目录。

2命名规则

如果想要有效的管理一个稍微复杂一点的体系，针时其中事物的一套统一、带层次

结构、清晰明了的命名准则就是必不可少而旦非常好用的工具。

活跃在生物学、化学、军队、监狱、黑社会、恐怖组织等各个领域内的大量有识先

辈们都曾经无数次地以实际行动证明了以上公理的正确性。除了上帝（设它可以改变世

间万物的秩序）以外，相信没人有实力对它不屑一顾。

在软件开发这一高度抽象而且十分复杂的活动中，命名规则的重要性更显得尤为突

第14页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

出。一套定义良好并且完整的、在整个项目中统一使用的命名规范将大大提升源代码的

可读性和软件的可维护性C

a）在引入细节之前，先说明一下命名规范的整体原则：

b）同一性

C）在编写一个子模块或派生类的时候，要遵循其基类或整体模块的命名风格，保

持命名风格在整个模块中的同一性。

d）标识符组成

e）标识符采用英文单词或其组合，应当直观且可以拼读，可望文知意，用词应当

准确。

D最小化长度&&最大化信息量原则

g）在保持一个标识符意思明确的同时，应当尽量缩短其长度。

h）避免过于相似

i）不要出现仅靠大小写区分的相似的标识符，例如“i”与"I"，"function"与

“Function”等等。

j）避免在不同级别的作用域中重名

k）程序中不要出现名字完全相同的局部变量和全局变量，尽管两者的作用域不同

而不会发生语法错误，但容易使人误解。

1）正确命名具有互尺意义的标识符

m）用正确的反义词组命名具有互斥意义的标识符，如："nMinValue.."nMaxValue",

"GetNarne（）.."SetName（）.....

n）避免名字中出现数字编号

尽量避免名字中出现数字编号，如Valuel,Value2等，除非逻辑上的确需要编号。这是为

了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省

事）。

2.1类/结构

a）除了异常类等个别情况（不希望被用户看作一个普通的、正常的类之情况）外,

C++类/结构的命名应该遵循以下准则:

第15页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

b）C++类/结构的命名

类的名称都要以大写字母“C”开头，后跟一个或多个单词。为便于界定，每个单词

的首字母要大写。

特别地，由于界面与其它类概念上的巨大差别，规定界面类要以大写字母“I”开头。

界面类描述一个服务（一组被命名的操作集合），在C++中，界面与其它类间的最大

区别在于，界面类中不包含任何数据结构（属性），也不包括任何具体的操作和实现，界

面类通常仅包含一组纯虚函数的声明而不包含任何实现和数据。在一些其它语言中，一

个界面也被称作一个接口及其实现契约。

另一个与接口相似的概念是类型，类型与接口的不同点在于，类型可以包含部分接

口的实现或包含些接口默认的或不完整的实现，个类型也可以包含些属性。规定

类型类要以大写字母“T”开头。例如：轿车类型叮Car”、线程类型Thread”等等。

在C++种，类型类也叫做结点类。

在现实世界中，类型和界面的区别往往比较微妙。在真实代码中，有些类除了包含

纯虚函数以外，也可能同时包含几个带简单默认实现的普通虚函数。例如：某个类中可

能包含一个（非纯虚）虚方法IsLoadable,并定义了该方法的默认实现：returnfalse;。

我们不难找出很多类似的例子。

以下是一些类型和界面的界定策略：

如果一个类中包含静态成员，则一定不是界面

如果一个类中包含属性，则一定不是界面

如果一个类中包含非虚方法，则一定不是界面

如果一个类中包含非公有成员，则一定不是界面

如果一个类中包含模板方法，则一定不是界面。

这里的模板方法是指那些调用了该类中其它虚函数的成员，这样的方法通常用于实

现针对某种应用的算法框架，这显然超出了界面的范畴。

在C++中，模板方法的另一个意思通常指使用函数模板的成员，由于C++函数模板

只能是非虚的，所以包含这种方法的类也一定不是界面。

通常定义那些不十分明确的接口时，先将其指定为一个界面，必要时再把它提升为

第16页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

一个类型。

模板类的命名规范与实体类相同。

C)为了更好地表示代码段之间的相关性和增加程序的可读性。我们经常会把一段

仅在某个函数内反复使用的代码片段封装为一个函数对象，并定义在这个函数

体内。对于这类实现功能简单，并且主要通过operator。来使用的类/结构，其

名称应当以大写字母“FO”开头，如:"FONameChecker”等。

d)推荐的组成形式

类的命名推荐用“名词“或“形容词+名词”的形式，例如：nCAnalyzer","CFaslVector';

''IUnknown11,^DEWriter'；"TTimer'1,"TThread1'....

a)不同于C十十类的暇念，传统的C结构体只是种将组数据捆绑在起的方

式。传统C结构体的命名规则为：

b)传统C结构体的命名

传统C结构体的名称全部由大写字母组成，单词间使用下划线界定，例如:

"SERVICE_STATUS","DRIVERJNFO"....

2.2函数

2.2.1函数的命名

函数的名称由一个或多个单词组成。为便于界定，每个单词的首字母要大写。

2.2.2推荐的组成形式

函数名应当使用“动词“或者”动词+名词”(动宾词组)的形式。例如：

,,GetName()"."SetVaIue()',."Erase()".,'Rese^e().....

2.2.3保护成员函数

保护成员函数的开头应当加上一个下划线以示区别，例如：”_SeiStale()..…

2.2.4私有成员函数

类似地，私有成员函数的开头应当加上两个下划线，例如：--Destroylmpi)..…

2.2.5私有成员函数的层次结构表示

通常来说，在一个类中，公有方法、保护方法和私有方法所完成的任务总是呈现一

种逐级依次细化的层次结构(意即：保护方法所实现的功能通常比该类中的公有方法更

第17页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

为细小琐碎；类似地，私有方法的功能也比其保护方法更具原子性)。

因此，对于遵循以上规则，并且功能较为复杂的类，在按照“公有、保护、私有”的

三级形式划分以后，如果其私有成员中仍然存在明显不同的功能粒度，则可以通过追加

更多下划线前缀的形式予以表示。

例如：由三个下划线开头的私有方法”—PushCdr”就要比同一类中，仅由两个下划线

开头的私有方法“_MergeConCall”所完成的功能粒度更细小、更琐碎；而四个下划线

开头的“CalcCompensate"则比"—PushCdr"完成的功能更具原子性。

如果发现类中的功能层数太多(从公有方法到最“原子”的私有方法间，一般不应该超

过7层)，那通常反应一个不良的设计。此时请检查这个类的功能是否过于臃肿，已使

接口显得不太清晰。另外一个常见的问题是将无需访问该类中私有或保护成员的功能

定义成了方法。第一个问题可以通过重新划分类层次结构或将一个类分裂为多个类等方

法解决。对于第二个问题，由于这些方法无需访问受限成员，大多数时候都可以把它们

转变成局部函数(放在无名空间或使用“static”前缀定义)。

2.2.6成员函数的下划线后缀命名

对一些本应该作为保护或私有成员的函数，由于设计方面的其它考虑(例如：灵活

性、功能等方面)将其提升为公有成员的，应该在其后面添加与其原本访问控制级别相

应的下划线后缀。

另外，对于其它不推荐直接使用的成员函数(例如：会引起兼容性或可移植性方面

问题的函数)，也应当在其后面加相应下划线提示。

例如：nioctl_()",,,SetSysOpt_(),\"GetSysOpt-O11,"PreParser_()M....

2.2.7回调和事件处理函数

回调和事件处理函数习惯以单词“On”开头。例如：10nTimer()”.“0nExil()..…

2.2.8虚函数

回调函数以外的虚函数习惯以“Do”开头,如："DoRefresh()”."_DoEncryption().....

2.3变量

a)变量应该是程序中使用最多的标识符了，变量的命名规范可能是一套C++命名

准则中最重要的部分:

第18页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

b)变量的命名

变量名由作用域前缀+类型前缀+一个或多个单词组成。为便于界定，每个单词的

首字母要大写。

c)对于某些用途简单明了的局部变量，也可.以使用简化的方式，如：i.jkx.y……

d)作用域前缀

作用域前缀标明说明

一个变量的可见

范围。作用域可

以有如下几种：

前缀

无局部变量

m_类的成员变量(member)

sm_类的静态成员变量(staticmember)

s_静态变量(static)

g-外部全局变量(global)

sg_静态全局变量(staticglobal)

gg-进程或动态链接库间共享的全局变量(globalglobal)

除非不得已，否则应该尽可能少使用全局变量。

关于全局变量和局部静态变量的依赖性问题和初始化时的线程安全性问题

e)类型前缀

类型前缀标明一说明

个变量的类型，

可以有如下几种:

前缀

n整型和位域变量(number)

C枚举型变量(enumeration)

C字符型变量(char)

b布尔型变量(bool)

f浮点型变量(float)

P指针型变量和迭代子(pointer)

第19页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

pfn指向函数的指针变量或指向函数对象的指针(poimeroffunction)

pm指向成员的指针(pointerofmember)

引用(reference),此前缀对「常引用(constreference)来说可以省略

r

g数组(grid)

fo函数对象(FunctionObject)

类的实例(instance)

对于经常用到的类，也可以定义一些专门的前缀，如：s(d::string和

std::ws:ring类的前缀可以定义为"st”,std::vector类的前缀可以定义为V等

等。

对于经常用到的类，也可以定义一些专门的前缀，如：std::stiing和

i

std::ws:ring类的前缀可以定义为“st"，std::vcctor类的前缀可以定义为V等

等。

对于经常用到的类，也可以定义一些专门的前缀，如：std::string和

std::ws:ring类的前缀可以定义为"si",std::vector类的前缀可以定义为"v"等

等。

0类型前缀可以组合使用，例如“gc”表示字符数组，“ppn”表示指向整型的指针的

指针等等。

g)数值前缀的特别记法

以“n”作为所有说明

整形前缀是由于

大多数情况下，

编写程序时不需

要过多考虑整形

的宽度，但在某

些场合中，整形

宽度是需要特别

注意并且仔细加

以区分的，这时

可使用如下记法

代替“n”前缀：

前缀

b字节(8bil,byte)

W字(16bit,word)

第20页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

dw双字(32bil,doubleword)

qw-或-nn四字(64bit,quadword)

bf位域(bitfield)

对浮点型变量也说明

有类似记法如下:

前缀

f单精度浮点(32bit,float)

d双精度浮点(64bil,double)

Id扩展精度浮点(80bit,longdouble)

h）推荐的组成形式

变量的名字应当使用“名词“或者”形容词+名词”。例如：nnCodcu,"m_nStateu,

“nMaxWidth"....

2.4常量

a）C++中引入了对常量的支持，常量的命名规则如下：

b）常量的命名

常量名由类型前缀+全大写字母组成，单词间通过下划线来界定，如:

cDELIMITER,nMAX_BUFFER。

类型前缀的定义与变量命名规则中的相同。

2.5枚举、联合、typedef

a）枚举、联合及typedef语句都是定义新类型的简单手段，它们的命名规则为：

b）枚举、联合的命名

c）由枚举、联合语句定义的类型名由全大写字母组成，单词间通过下划线来界定,

如：FAR_PROC,ERROR_TYPE....

d）typedef的命名

通常情况下，typedef语句定义的类型名，其命名规范与枚举及联合语句相同，也采

第21页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

用大写字母加下划线的原则。但是在定义一个模板类实例的别名时，为清晰起见,

可以考虑酌情使用类的命名原则，例如：

typedefCWriter<CSysFile>CSysFileWriter;

typcdefstd::vector<int>VINT;

2.6宏、枚举值

a）宏、枚举值的命名

宏和枚举值由全大写字母组成，单词间通过下划线来界定，如：ERRORJJNKNOWN,

OP_STOP。

2.7名空间

C十十名空间是“类”概念的种退化（大体相当丁•只包含静态成员且不能实例化的

类）。它的引入为标识符名称提供了更好的层次结构，使标识符看起来更加直观简捷，同

时大大降低了名字冲突的可能性。

a）名空间的命名规则包括：

b）名空间的命名

名空间的名称不应该过长，通常都使用缩写的形式来命名。

例如，一个图形库可以将其所有外部接口存放在名空间"GLIB”中，但是将其换成

“GRAPHIC_LIBRARY”就不大合适。

如果碰到较长的名空间，为了简化程序书写，可以使用：

namespacenew_name=old_long_name;

语句为其定义一个较短的别名。

3代码风格与版式

代码风格的重要性怎么强调都不过分。一段稍长一点的无格式代码基本上就是不可

读的。

a）先来看一下这方面的整体原则：

b）空行的使用

空行起着分隔程序段落的作用。空行得体（不过多也不过少）将使程序的右局更加

清晰。空行不会浪费内存，虽然打印含有空行的程序是会多消耗一些纸张，但是值得。

第22页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

所以不要舍不得用空行。

在每个类声明之后、每个函数定义结束之后都要加2行空行。

c）在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方应加空行分

隔。

d）语句与代码行

一行代码只做一件事情，如只定义一个变量，或只写一条语句。这样的代码容易阅

读，并且方便于写注释。

e）uif\Hfor\nwhile\ndo'\utry\"catchH等语句自占一行，执行语句不得紧跟

其后。不论执行语句有多少都要加。这样可以防止书写和修改代码时出

现失误。

f）缩进和对齐

程序的分界符和应独占一行并且位于同一列，同时与引用它们的语句左

对齐。

”{}”之内的代码块在右边一个制表符（4个半角空格符）处左对齐。如果出

现嵌套的”{}”，则使用缩进对齐。

如果一条语句会对其后的多条语句产生影响的话，应该只对该语句做半缩进（2个

半角空格符），以突出该语句。

例如：

void

Function（intx）

{

CScssionLockiLock（mxLock）;

for（初始化；终止条件；更新）

（

H...

H...

}

第23页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

catch(constexception&err)

II...

}

catch(...)

(

n...

}

H...

)

g)最大长度

h)代码行最大长度宜控制在70至80个字符以内。代码行不要过长，否则眼睛看

不过来，也不便于打印(2009年更新：随着GUI开发环境和高分宽屏的普及，此

规则可以视情况适当放宽)。

i)长行拆分

长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首(以便突出操作

符)。拆分出的新行要进行适当的缩进，使排版整齐，语句可读。

例如：

if((very_longer_variable1>=very_longer_variable2)

&&(very_longer_variable3<=very_longer_variable4)

&&(very_longer_variable5<=very_longer_variable6))

(

DoSomethingO;

)

j)空格的使用

关键字之后要留空格,象“const"、“virtual"、“inline"、“case”等关键字之后至少要

留一个空格，否则无法辨析关键字。象"if.Hfor'\nwhile'\"catch'1等关键字之后应留

一个空格再跟左括号”(二以突出关键字。

函数名之后不要留空格，紧跟左括号"('；以与关键字区别。

向后紧跟。而向前紧跟，紧跟处不留空格。

第24页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

之后要留空格，如Function(x,y,z)。如果不是一行的结束符号，其后要留空

格，如for(initialization;condition;upda(e)o

赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如”二“、二”、

“〈二“等二元操作符的前后应当加空格。

一元操作符如T、(地址运算符)等前后不加空格c

象这类操作符前后不加空格。

对于表达式比较长的for、do、while>switch语句和if语句，为了紧凑起见可以

适当地去掉一些空格，如for(i=0;i<10;i++)和if((a<=b)&&(c<=d))等。

例如：

k)voi.Funu1(in.x.in.y.in.z);良好的风格

voi.Func.(in.x,in.y,in.z);./.不良的风格

/===========================================================

i.(yea.>.2000)./.良好的风格

if(year>=2000)./.不良的风格

i.((a>=b.&.(c〈=d))J.良好的风格

if(a>=b&&c<=d)不良的风格

/===========================================================

fo.(i=0.i<lO.i++)良好的风格

for(i=0;i<10;i++)不良的风格

fo.(..0...10..++./.过多的空格

/===========================================================

..……b;.良好的风格

x=a<b?a:b;.不好的风格

第25页共66页

工作文件文件编号：

软件设计规范版号/修改状态：A/0

/===========================================================

int...&y;.良好的风.

in.....y;.不良的风.

/.===========================================================

arrayf5..0;../.不要写.arra..…0;

a.FunctionO;../.不要写...Function。；

b->Function();.不要写..-.Function。；

1)修饰符的位置

为便于理解，应当将修饰符和“&“紧靠数据类型。

例如：

m)char*name;

int*x;

mty;//为避免y被误解为指针，这里必须分行写。

int*Function(void*p);

n)注释

注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，不可放在下方。

边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不

再有用的注释要删除。

注释应当准确、易懂，防止注释