软件开发规范

时间:2022-12-15 09:12:59
我总结的一些软件开发规范 
作者:田进恩

 

为了提高软件开发质量,降低开发周期,增强代码的可重用性和易读性,使软件便于维护,开发人员间便于交流和协作,特总结出开发规范,以为参考。

一. 原则:

1. 软件工程化
2. 模块化
3. 能简单不复杂
4. 强调团队协作
5. 强调创新和特色

二. 具体规范:

1. 命名规范
命名应尽量使用匈牙利命名法,变量名或函数名中使用大写字符来区分各个部分,以便于记忆和阅读。如bPatchMinute, DeleteDirInfo()。全局(包括类中的)变量用长名字,局部变量用短名字。
类成员变量前一般应加上m_,全局变量加上g_,仅与本模块有关的变量加上l_,紧接着是变量的类型。 
整型: n,i
长整型: l
无符号整型: u
无符号长整型:dw
字符: ch
布尔量: b
浮点数: f
双精度浮点: d
字符串: str,lpsz,sz,p,lp,ac,
指针: p
字节指针: pb
无符号指针: pv
字符指针: lpsz
整型指针: lpn
文件指针: fp
如:
m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr,
 lpnSysDoomType,uMsgID,m_pProgress

局部变量应尽量易懂简洁,使用常见的变量,如
Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename

临时变量,如ltmp,ftmp,tmpStr,tempStr,

函数命名也应该见名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo()
常见的函数
Init, OpenAll, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_,
 Check_, Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex。

宏命名和typedef定义类型应详细,避免重复,一律为大写,如

#define DEL_EMPTY(a) {if (a) {delete a;a=NULL;}}
#define SUCCESS 0
#define FAIL -1

typedef struct
{
char lpzSource[100];
char lpzTitle[100];
char lpzURL[194];
short nType;
long npos;
long nlen;
}ATTBODY,*LPATTBODY; (指针前加LP)

自定义消息从WM_USER开始
#define MYAPP_MESSAGE WM_USER+0x1001

2. 代码规范
有些不易理解的变量或函数应作注释,难懂的代码要有注解,在文件的开始处有该文件的用途描述。一定要保持注释的一致性。

代码组织要清晰,{,},(,),if,else,do,while,for,case等要对应整齐,少用空格,缩进全部用Tab键。变量的定义要集中,函数间要有空行分开,一个程序中的空行数目最好占8%-16%。多态函数和功能相近的函数集中放在一起。

代码应该简洁、清楚并讲述了所发生的一切,我们的目标应该是写出最清晰的代码,而不是最巧妙的代码。例如如果是MFC多文档程序,就要严格按照其生成的框架写代码。尽量使用编译器已经提供的函数,不必花时间另行编写。例如系统已经有qsort函数,可直接拿来排序用。

某些公用代码要注意多平台易移植,最好使用标准C。

代码的重用要仔细,要将相关的代码也拷贝过来,注意那段代码也许不适合你的应用场合。

删掉从来没有用过的函数或变量,大篇幅注释掉的代码行也应删除,以免使程序混乱难读。

3. 工程文件组织规范
一个工程往往包含很多很多文件(*.h,*.cpp,*.inc,*.lib,资源文件等),向工程中加入文件或删除工程中的文件要慎重,避免把工程损坏。工程中不起作用的文件或类应删除,工程目录下的非工程文件也应该移走,保持工程的清洁,避免混淆难于管理。工程文件如果很多,应归类。

在VC环境下,建议将常用的头文件全部放入stdafx.h中,而在每个cpp开始处嵌入stdafx.h。避免头文件的交叉引用,如果有严重的交叉引用,适当使用类的声明。

将独立性比较强的模块抽出来,做成DLL,控件或COM组件,该模块可单独编写和测试,也增强了其可重用性。

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

工程的版本控制要严格,版本格式为xx.xx.xx,必要时使用Build次数或日期。高版本尽量兼容低版本的用法、数据或协议。

工程的编译宏定义和工程参数设置应正确,每作一个新工程时应检查工程参数是否正确。
建议字节对齐方式为1字节对齐。

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

4. 类组织规范
类一般有两个文件,一个头文件,一个实现体CPP。

类力求封装好,严格区分public,private,protect等作用域,如果一个函数与本类有莫大的关系,可以作为该类的静态成员函数,不用或少用友元函数等破坏类封装性的方法和技巧。 如果一些结构或宏仅与本类有关,可在类头文件中定义。

类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋NULL,析构时DEL_EMPTY它,以免内存泄露。

5. 用户界面规范
有四大类型的用户界面:对话框、单文档界面、多文档界面、其它界面

对话框要易用且简洁,字体和控件的组织搭配要得体,能简单不复杂,各控件的焦点、Tab顺序等要讲究,视应用场合要适当支持键盘。在简洁易用的前提下,力求个性化,设计得更加友好。程序各对话框的风格要保持一致。

单文档和多文档界面的程序功能可以做得很强,也便于扩充和管理。其中菜单、工具栏、状态栏等设计要有特色。菜单按一定的分类弹出,必要时设计成多套菜单,在重要的窗口或区域应能弹出右键,实现常见操作。工具栏上放最常用的操作按钮,必要时动态更换按钮。状态栏显示足够多的有用信息。
消息主控在Mainframe中,单文档的主控也可在View中,所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成,具体的数据处理放在单独的文件中或设计成类。在App类中实现Ini读写,各数据对象的定义和析构,全局变量的赋值和初始计算,存盘退出等。各视图的OnDraw和GDI画图尽量使用内存位图的方式,以免闪烁。

其它还有ATL,控制台,嵌入式程序界面等,也有作为其它容器如IE中的插件等,此类程序可能不用MFC,而采用COM组件等方法实现。

6. 疑难解答和Bug调试方法
勤问、善于问。在不打扰正常工作的前提下,开发人员间应相互帮助,聚思广益,也许你的问题或Bug就是他人的前车之鉴。

从各种途径请求解答。专业书、教材、期刊、电子文档以及国际标准文献、RFC等,Internet上专业网站、论坛、专家组等。

Bug的出现总是有一定的原因的,冷静查找,不要总是拘泥于某一个小局部,换一个想法、从另外一个角度也许让你柳暗花明。使用一些辅助开发或调试工具,如Spy++,Process Viewer,系统监视器等。

拓宽知识面。多参阅其它编程语言、数据库知识、编译原理、网络协议等,熟悉硬件设备、底层汇编、数字逻辑电路等。使用和揣摩其它软件功能和界面,集百家之长,做出有创新意义和有特色的功能性软件。

三. 一些习惯:

我认为比较好的习惯:

1.if(0 == GetDataType(…))比if(GetDataType(…) == 0) 好,纵使误将==写成=,在编译一层就会报错。
2. 
#define MAX_DOWNLOADNUM 20
struct DownInfo m_DownInfo[MAX_DOWNLOADNUM];
在代码中尽量不用具体的大小数值,定义成宏,便于以后维护。
3.
CUSTXG_CONTABLE g_lpCustCon[] = 
{
{"数值串1",C_ZGB,C_CUSTJBM,C_VT_FBJ,"万"},
{"数值串2",C_ZSZ,C_CUSTJBM,C_VT_FBJ,"万"},

{"数值比例",C_WTB,C_CUSTHQ,C_VT_FBJ,"%"}
};
int g_nCustNum = sizeof(g_lpCustCon)/sizeof(CUSTXG_CONTABLE);
g_ nCustNum自动适应g_lpCustCon的大小。
4. 
函数定义short GetInputType( const char * lpzInput)比short GetInputType (char * lpzInput)好,以免lpzInput在函数体中被破坏。
5. 
协议包头定义成:
typedef struct tagDataHeader

struct{
unsigned char Version:4;
unsigned char HeaderFlag:2;
unsigned char Reserved:2;//保留Bits位
}Info;
long nOther;
long Reserved; //保留4个字节
} DATAHEADER;
定义有一定的保留字段,供以后扩充使用。
6.
变量在定义时赋初值,类析构时或程序退出时判断释放所有变量。
7.
编码空间一定要充分预留,编码时注意可扩充性。

我认为不好的习惯:

1. 代码中是"+2","+4",而不是"+sizeof(short)","+sizeof(int)"。
2. filename[40],而不是filename[MAX_PATH]。
3. GDI资源使用完后不释放,位图、笔刷等用完后不Select出来。这样会将导致系统Gdi资源丢失或内存泄露。
4. 大量使用无符号型变量。无符号变量在判断时易造成错误,甚至死循环,尽量少用。
5. 使用malloc,free不使用new,delete,大量使用realloc。new,delete是规范的C++语法,通用性强,realloc易造成内存抖动。
6. #define square(x) (x)*(x)
宏的体应加括号,否则容易出问题,如1/square(x)将被替换1/(x)*(x)

以上仅是我总结的一些,比较少,希望能抛砖引玉,请大家补充 



版权所有:UML软件工程组织