华为程序开发规范

《华为程序开发规范》由会员分享，可在线阅读，更多相关《华为程序开发规范（11页珍藏版）》请在金锄头文库上搜索。

1、Panorama 系统程序开发规范之二系统程序开发规范之二1.匈牙利命名规则匈牙利命名规则变动前缀类型aArray bBoolean byByte cChar/有符号型字符 cbChar Byte/无符号型字符（没多大用处） crColorRef/颜色参考值 cx,cyLength of x,y (ShortInt)/坐标差（长度） dwDouble Word fnFunction hHandle iInteger m_Member of a class nShort Integer npNear Pointer pPointerlpLong Pointer (str)sString szSt

2、ring with Zero End/以字符0结尾的字符串 tmText/文本内容 wWord x,yCoordinate/坐标2.Panorama 系统的命名约定系统的命名约定2.1 VC 中变量命名时的前缀约定中变量命名时的前缀约定Arraya./例：CStringArray saText BOOLb. UINTn. inti. shortn. longl. WORDw. DWORDdw. floatf. charc. char*psz. TCHAR*psz. LPCTSTRlpsz. CStringstr. COLORREFcr. LPLOGPALETTE lp.(包括 LP 开头的类型

3、都是这样) POINTpt. CPointpt. HANDLEh. HGLOBALh.(包括 H 开头的类型都是这样)说明： 1.如果是指向上述类型的指针，就在上面规范前加 “p“ ; 2.如果是指向上述类型的双重指针，就在上面规范前加 “pp“ ; 3.如果是类成员变量，则在上面规范前加 “m_“; 4.全局变量,则在上面规范前加 “g_“; 5.在类型前加了“const“,命名约定不变;2.2 VC 中变量命名时的后缀约定中变量命名时的后缀约定 1.MFC 类 CWnd*p.Wnd省去的地方一般为该类的用途 (如果是某一个类的成员，则还应该在前 加 “m_“)又如：CView* p.Vie

4、w2.3 局 部 变 量 应 尽 量 易 懂 简 洁 ， 使 用 常 见 的 变 量 ， 如 Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename 临时变量，如 ltmp,ftmp,tmpStr,tempStr 。 。 。2.4 函数命名也应该见名知意。 如 CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo() 常见的函数 Init_, Open_, Create_, Get_, Set_, Read_, Load_, Write_, St

5、art_, Stop_, Check_,Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex2.5 禁止使用汉语拼音来命名；2.6 在代码中尽量不用具体的大小数值，定义成宏，便于以后维护,如： #define MAX_DOWNLOADNUM 20 struct DownInfo m_DownInfoMAX_DOWNLOADNUM;2.7 VC 中一些控件的缩写： ComboBoxcmb Editedt Dialogdlg ListBoxlst Picturepic Animateani3. 编排编排3.1 函数间要有空行分开，

6、一个程序中的空行数目最好占 8%-16% ;3.2 变量的定义尽可能放在最开始处，多态函数和功能相近的函数集中放在一起;3.3声明变量时对齐变量名,并在定义时加以注释说明；4. 程序开发环境规约程序开发环境规约4.1 工作目录结构的规定: project name(项目名称) bin执行文件 log日志文件 lib库文件 include头文件 src源程序 dat数据文件4.2 工程中不起作用的文件或类应删除，工程目录下的非工程文件也应该移走，保持工程的 清洁，避免混淆难于管理;4.3 在 VC 环境下，建议将常用的头文件全部放入 stdafx.h 中，而在每个 cpp 开始处嵌入 stdaf

7、x.h。避免头文件的交叉引用，如果有严重的交叉引用，适当使用类的声明。4.4 将独立性比较强的模块抽出来，做成 DLL，控件或 COM 组件，该模块可单独编写和测 试，也增强了其可重用性。4.5 一个比较大的工程应留有一定的消息接口或插件接口等。4.6 工程的版本控制要严格，版本格式为 xx.xx.xx，必要时使用 Build 次数或日期。高版本 尽量兼容低版本的用法、数据或协议。4.7 工程的编译宏定义和工程参数设置应正确，每作一个新工程时应检查工程参数是否正 确。建议字节对齐方式为 1 字节对齐。5. 程序备份程序备份5.1. 要有备份记录 备份时注明备份日期和主要增加的功能 5.2. 定

8、时备份 根据程序量的多少，可以每天备份一次，也可以半天备份。5.3. 多种介质备份 至少在硬盘上做 2 个备份，在软盘上做一个备份；在使用他人主机进行备份时，不可放 于没有密码保护的 ftp 服务器上，可以发送到自己的 email 信箱中进行备份。5.4 在软盘上备份时， 应该去掉中间文件和执行文件， vc 可以自动生成的文件如*.clw, *.ncb, *.opt 等也可删除，最后压成一个 zip 文件，复制到软盘中。6.VC 程序界面设计规范程序界面设计规范6.1.颜色选择： 6.1.1 基调应以 WINDOWS 颜色（灰色）为主，同一个窗体中除白、黑、灰色之外，其它 的颜色总数不宜超过

9、3 种 （对以生产和学习为目的的软件而言， 娱乐性软件可以做得花哨一 些； 6.1.2 窗体和控件（除 EDIT、RICH EDIT 等编辑控件外）的背景色也宜用灰色，当一个 控件有输入焦点或鼠标焦点时，可以用较明亮的颜色; 6.1.3 非激活状态下，字体前景宜用黑色，背景用灰色；6.2.字体的选择： 6.2.1 汉字字体一般选宋体，字体大小选 10 号； 6.2.2 一般选系统常用的字体，绝对不要选自己加入的而系统没有的字体；6.3.图片的选择 6.3.1 在窗体的工具拦中的按钮可以用图标，文字可以写上也可以不写，如果不写则一定 要使用 tip 来提示用户该按钮完成的功能； 6.3.2 在按

10、钮中使用的图片要能表达按钮对应功能的意义； 6.3.3 不宜对普通的按钮只用图标做外观；6.4.操作的便利性 6.4.1 为方便用户的使用，所有的输入控件应该按 tab 键和回车键排序，特别是密码输入 时，应该能用回车切换输入框的焦点；6.5.数据安全 6.5.1 对程序的退出、写数据等有破坏可能或数据丢失可能的操作应该给用户一次确认的 机会；6.6.帮助文件 6.6.1 帮助文件宜用 html 格式，因为 hlp 格式的文件只能在 windows 中用；6.7.窗体大小的确定 6.7.1 一般窗体的大小应该可以让用户自己调整，窗体的初始长宽比例为 4：3 6.7.2 要考虑到用户可能会用到不

11、同的分辨率，在开发时应使用当时流行的分辨率； 6.7.3 除非必要，否则不宜用模态窗体,但可以让用户选择使窗体成为模态窗体； 6.7.4 应用程序的大小不固定时(拖动窗口的右下角时可以改变窗体大小)，应处理窗体变 化时窗体内各控件大小和位置的变化；6.8.视图的选择(单/多文档界面类型) 6.8.1 对于一个简单的文本编辑器应用程序，选择 CEditView; 6.8.2 对于一个能编辑多信息文本格式( RT F )文件的应用程序，选择 CRichEditView(这一 选择将导致应用程序为文档类选择 CRichEditDoc 类); 6.8.3 对于一个图形应用程序，选择 CScrollVi

12、ew; 6.8.4 对于一个简单的监控或帐目管理应用程序，选择 CListView; 6.8.5 要着手创建一个资源管理器类型的应用程序，请选择 CTreeView(在以后的步骤中, 可以手工添加一个 CListView); 6.8.6 在对话框模板外创建一个视图， 选择 CFormView(一个对话框是一个被几个控件窗口 占据的窗口，诸如按钮和编辑框);6.9. MFC 应用程序类型的选择： 6.9.1 如果创建一个用户界面需求有限的应用程序，或如果想界面完全单一，那么就创建 一个对话框应用程序。 典型的对话框应用程序包括配置硬件设备的应用程序、 屏幕保护程序 和游戏程序等; 对话框要易用且

13、简洁， 字体和控件的组织搭配要得体， 能简单不复杂， 各控件的焦点、 Tab 顺序等要讲究，视应用场合要适当支持键盘。在简洁易用的前提下，力求个性化，设计 得更加友好。程序各对话框的风格要保持一致。6.9.2 如果应用程序要编辑一个文档，应该选择单/多文档界面类型。这里的“编辑一个文 档”是广义上的意思，所指的文档可以是一个文本文件、电子数据表文件、第三方数据库的 一个或多个表、或者是自己的二进制文件，甚至可以是大量硬件设备的储存设置。编辑仅仅 表示对其中任何一个类型的文档进行添加、删除或修改操作。 6.9.3 单文档界面应用程序一次只允许处理一个文档。如果应用程序实际上一次只需处理 一个文档

14、，诸如监视一组硬件设备的应用程序，那么应该选择单文档界面；否则应该创建一 个多文档界面应用程序，即使在开始时一次编辑多个文档并未显出有任何好处。 6.9.4 一个多文档界面应用程序允许一次编辑多个文档，它并不比一个单文档界面应用程 序复杂，但却带来了一次至少查看多个文档的方便。 6.9.5 在重要的窗口或区域应能弹出右键， 实现常见操作。 工具栏上放最常用的操作按钮， 必要时动态更换按钮。状态栏显示足够多的有用信息。消息主控在 Mainframe 中，单文档的 主控也可在 View 中，所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成，具 体的数据处理放在单独的文件中或设计成类。在 A

15、pp 类中实现 Ini 读写，各数据对象的定义 和析构，全局变量的赋值和初始计算，存盘退出等。各视图的 OnDraw 和 GDI 画图尽量使 用内存位图的方式，以免闪烁。6.10. 操作进度指示 6.10.1 把鼠标光标暂时变成沙漏形状，以指示一个漫长的操作，要求用户应该等待。 6.10.2 可以用沙漏光标指示短暂的等待。 对于长时间的等待， 可以考虑使用一个无模式对 话框，并在上面显示简短的消息，描述正进行什么处理;6.11. 分隔线控件 6.11.1 为统一起见不要使用分组框、按钮等控件做分隔线，应按如下做法：用 Picture Control，属性设为 Etched 和 Frame，使该

16、控件缩小到一条直线；7.7. 其他其他7.1. 为保证系统间的兼容性,不使用 int 类型(因为不同系统之间的存储字节长度往往 不同),应使用 long 或 short 型。 7.2. 头文件名应小写,如用#include“abcdef.h”; 7.3. 本系统中注释统一只用“/” ； 7.4if(0 = GetDataType()比 if(GetDataType() = 0) 好，纵使误将=写成=，在编译一 层就会报错。 7.5函数定义 short GetInputType( const char * lpzInput)比 short GetInputType (char * lpzInput) 好，以免 lpzInput 在函数体中被破坏。 7.6 变量在定义时赋初值，类析构时或程序退出时判断释放所有变量。 7.7 编码空间一定要充分预留，编码时注意可扩充性, 如：定义保留字段，供以后扩充使用 7.8 不要大量使用无符号型变量。 无符号变量在判断时易造成错误， 甚至死循环， 尽量少用。 7.9 少使用 malloc