Panorama系统程序开发规范之二 l匈牙利命名规则 变动前缀类型 Ar Byte Char ∥符号型字符 Char Byte ∥无符号型字符(没多大用处) cr Color Ref ∥颜色参考值 ∥坐标差(长度) Double word fn Near pointer p String with zero end ∥以字符0结尾的字符串 Text ∥文本内容 Word Coordina ∥坐标
Panorama 系统程序开发规范之二 1.匈牙利命名规则 变动 前缀 类型 a Array b Boolean by Byte c Char //有符号型字符 cb Char Byte //无符号型字符（没多大用处） cr ColorRef //颜色参考值 cx,cy Length of x,y (ShortInt) //坐标差（长度） dw Double Word fn Function h Handle i Integer m_ Member of a class n Short Integer np Near Pointer p Pointer lp Long Pointer ×(str) s String sz String with Zero End //以字符'\0'结尾的字符串 tm Text //文本内容 w Word x,y Coordinate //坐标
2 Panorama系统的命名约定 2VC中变量命名时的前缀约定 ∥例小: CString Array sa Text BOOL UINT bn. short WORD DWORD dw f char* TCHAR* LPCTSTR lpsz CString COLORREF cr LPLOGPALETTE lp(包括LP开头的类型都是这样 POINT CPoint HANdLE h HGLObAL h (包括H开头的类型都是这样) 说明 如果是指向上述类型的指针,就在上面规范前加"p"; 2如果是指向上述类型的双重指针,就在上面规范前加"pp 3如果是类成员变量,则在上面规范前加"m"; 4全局变量,则在上面规范前加"g 5在类型前加了" const",命名约定不变 22VC中变量命名时的后缀约定 1MFC类 CWnd*p.Wnd省去的地方一般为该类的用途(如果是某一个类的成员,则还应该在前 加"m")又如:Cvew*p.view 23局部变量应尽量易懂简洁,使用常见的变量,如Num, nCount, i,j, k, n,len, pos offset nReadnum, index,nRet;ret, string, filename临时变量,如ltmp, tmp, tmpStr; tempStr 24函数命名也应该见名知意。如 CalcAllDataStyle(), Read Doc DataFrom Time(, GetIndexlnfo 常见的函数Init,Open, Create,Get,Set,Read_,Load_,Wite, Start,Stop, Check
2.Panorama 系统的命名约定 2.1 VC 中变量命名时的前缀约定 Array a... //例：CStringArray saText BOOL b... UINT n... int i... short n... long l... WORD w... DWORD dw... float f... char c... char* psz... TCHAR* psz... LPCTSTR lpsz... CString str... COLORREF cr... LPLOGPALETTE lp... (包括 LP 开头的类型都是这样) POINT pt... CPoint pt... HANDLE h... HGLOBAL h... (包括 H 开头的类型都是这样) 说明： 1.如果是指向上述类型的指针，就在上面规范前加 "p" ; 2.如果是指向上述类型的双重指针，就在上面规范前加 "pp" ; 3.如果是类成员变量，则在上面规范前加 "m_"; 4.全局变量,则在上面规范前加 "g_"; 5.在类型前加了"const",命名约定不变; 2.2 VC 中变量命名时的后缀约定 1.MFC 类 CWnd* p...Wnd 省去的地方一般为该类的用途 (如果是某一个类的成员，则还应该在前 加 "m_")又如：CView* p...View 2.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_, Start_, Stop_, Check_
Test Fill Process. Sort. Do Select Is. Exist. Ex 2.5禁止使用汉语拼音来命名 26在代码中尽量不用具体的大小数值,定义成宏,便于以后维护如: #define MAX dOwnloadnUm 20 struct Downlnfo m DownInfo[MAX DOWNLOADNUM 2.7VC中一些控件的缩写 ComboBox cmb Edit Animate 3.编排 3.1函数间要有空行分开,一个程序中的空行数目最好占8%-16%; 3.2变量的定义尽可能放在最开始处,多态函数和功能相近的函数集中放在一起 33声明变量时对齐变量名并在定义时加以注释说明; 4.程序开发环境规约 4.1工作目录结构的规定 project name(项目名称) -bin 执行文件 日志文件 库文件 头文件 源程序 数据文件 4.2工程中不起作用的文件或类应删除,工程目录下的非工程文件也应该移走,保持工程的 清洁,避免混淆难于管理; 43在ⅤC环境下,建议将常用的头文件全部放入 stdafx h中,而在每个cpp开始处嵌入 stdafx h。避免头文件的交叉引用,如果有严重的交叉引用,适当使用类的声明
Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex… 2.5 禁止使用汉语拼音来命名； 2.6 在代码中尽量不用具体的大小数值，定义成宏，便于以后维护,如： #define MAX_DOWNLOADNUM 20 struct DownInfo m_DownInfo[MAX_DOWNLOADNUM]; 2.7 VC 中一些控件的缩写： ComboBox cmb Edit edt Dialog dlg ListBox lst Picture pic Animate ani 3. 编排 3.1 函数间要有空行分开，一个程序中的空行数目最好占 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 开始处嵌入 stdafx.h。避免头文件的交叉引用，如果有严重的交叉引用，适当使用类的声明
44将独立性比较强的模块抽出来,做成DLL,控件或COM组件,该模块可单独编写和测 试,也增强了其可重用性。 4.5一个比较大的工程应留有一定的消息接口或插件接口等 46工程的版本控制要严格,版本格式为xxxx,必要时使用Buld次数或日期。高版本 尽量兼容低版本的用法、数据或协议。 47工程的编译宏定义和工程参数设置应正确,每作一个新工程时应检查工程参数是否正 确。建议字节对齐方式为1字节对齐。 5.程序备份 5.1.要有备份记录 备份时注明备份日期和主要增加的功能 52.定时备份 根据程序量的多少,可以每天备份一次,也可以半天备份。 53.多种介质备份 至少在硬盘上做2个备份,在软盘上做一个备份;在使用他人主机进行备份时,不可放 于没有密码保护的fp服务器上,可以发送到自己的emai信箱中进行备份。 54在软盘上备份时,应该去掉中间文件和执行文件,vc可以自动生成的文件如*clw,*ncb *opt等也可删除,最后压成一个zip文件,复制到软盘中。 6.VC程序界面设计规范 6.1.颜色选择: 61.1基调应以 WINDOWS颜色(灰色)为主,同一个窗体中除白、黑、灰色之外,其它 的颜色总数不宜超过3种(对以生产和学习为目的的软件而言,娱乐性软件可以做得花哨 些 6.1,2窗体和控件(除EDIT、 RICH EDIT等编辑控件外)的背景色也宜用灰色,当一个 控件有输入焦点或鼠标焦点时,可以用较明亮的颜色 61.3非激活状态下,字体前景宜用黑色,背景用灰色:; 62字体的选择: 621汉字字体一般选宋体,字体大小选10号: 622一般选系统常用的字体,绝对不要选自己加入的而系统没有的字
4.4 将独立性比较强的模块抽出来，做成 DLL，控件或 COM 组件，该模块可单独编写和测 试，也增强了其可重用性。 4.5 一个比较大的工程应留有一定的消息接口或插件接口等。 4.6 工程的版本控制要严格，版本格式为 xx.xx.xx，必要时使用 Build 次数或日期。高版本 尽量兼容低版本的用法、数据或协议。 4.7 工程的编译宏定义和工程参数设置应正确，每作一个新工程时应检查工程参数是否正 确。建议字节对齐方式为 1 字节对齐。 5. 程序备份 5.1. 要有备份记录 备份时注明备份日期和主要增加的功能 5.2. 定时备份 根据程序量的多少，可以每天备份一次，也可以半天备份。 5.3. 多种介质备份 至少在硬盘上做 2 个备份，在软盘上做一个备份；在使用他人主机进行备份时，不可放 于没有密码保护的 ftp 服务器上，可以发送到自己的 email 信箱中进行备份。 5.4 在软盘上备份时，应该去掉中间文件和执行文件，vc 可以自动生成的文件如*.clw, *.ncb, *.opt 等也可删除，最后压成一个 zip 文件，复制到软盘中。 6. VC 程序界面设计规范 6.1.颜色选择： 6.1.1 基调应以 WINDOWS 颜色（灰色）为主，同一个窗体中除白、黑、灰色之外，其它 的颜色总数不宜超过 3 种（对以生产和学习为目的的软件而言，娱乐性软件可以做得花哨一 些； 6.1.2 窗体和控件（除 EDIT、RICH EDIT 等编辑控件外）的背景色也宜用灰色，当一个 控件有输入焦点或鼠标焦点时，可以用较明亮的颜色; 6.1.3 非激活状态下，字体前景宜用黑色，背景用灰色； 6.2.字体的选择： 6.2.1 汉字字体一般选宋体，字体大小选 10 号； 6.2.2 一般选系统常用的字体，绝对不要选自己加入的而系统没有的字体；
63图片的选择 631在窗体的工具拦中的按钮可以用图标,文字可以写上也可以不写,如果不写则一定 要使用tp来提示用户该按钮完成的功能 632在按钮中使用的图片要能表达按钮对应功能的意义; 633不宜对普通的按钮只用图标做外观 64操作的便利性 641为方便用户的使用,所有的输入控件应该按tab键和回车键排序,特别是密码输入 时,应该能用回车切换输入框的焦点 65数据安全 651对程序的退出、写数据等有破坏可能或数据丢失可能的操作应该给用户一次确认的 机会: 66帮助文件 661帮助文件宜用html格式,因为hp格式的文件只能在 windows中用; 67窗体大小的确定 67.1一般窗体的大小应该可以让用户自己调整,窗体的初始长宽比例为4:3 672要考虑到用户可能会用到不同的分辨率,在开发时应使用当时流行的分辨率 67.3除非必要,否则不宜用模态窗体但可以让用户选择使窗体成为模态窗体 674应用程序的大小不固定时(拖动窗口的右下角时可以改变窗体大小),应处理窗体变 化时窗体内各控件大小和位置的变化 68.视图的选择(单多文档界面类型) 681对于一个简单的文本编辑器应用程序,选择 CEditview, 682对于一个能编辑多信息文本格式(RTF)文件的应用程序,选择 CRich Edit view这 选择将导致应用程序为文档类选择 CRichEditDoc类) 683对于一个图形应用程序,选择 CScrollview, 684对于一个简单的监控或帐目管理应用程序,选择CLisⅤiew, 6.8.5要着手创建一个资源管理器类型的应用程序,请选择 CTree view(在以后的步骤中 可以手工添加一个 CList View) 686在对话框模板外创建一个视图,选择 CForm View(一个对话框是一个被几个控件窗口 占据的窗口,诸如按钮和编辑框) 69.MFC应用程序类型的选择: 691如果创建一个用户界面需求有限的应用程序,或如果想界面完全单一,那么就创建 一个对话框应用程序。典型的对话框应用程序包括配置硬件设备的应用程序、屏幕保护程序 和游戏程序等 对话框要易用且简洁,字体和控件的组织搭配要得体,能简单不复杂,各控件的焦点 Tab顺序等要讲究,视应用场合要适当支持键盘。在简洁易用的前提下,力求个性化,设计 得更加友好。程序各对话框的风格要保持一致
6.3.图片的选择 6.3.1 在窗体的工具拦中的按钮可以用图标，文字可以写上也可以不写，如果不写则一定 要使用 tip 来提示用户该按钮完成的功能； 6.3.2 在按钮中使用的图片要能表达按钮对应功能的意义； 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 要考虑到用户可能会用到不同的分辨率，在开发时应使用当时流行的分辨率； 6.7.3 除非必要，否则不宜用模态窗体,但可以让用户选择使窗体成为模态窗体； 6.7.4 应用程序的大小不固定时(拖动窗口的右下角时可以改变窗体大小)，应处理窗体变 化时窗体内各控件大小和位置的变化； 6.8.视图的选择(单/多文档界面类型) 6.8.1 对于一个简单的文本编辑器应用程序，选择 CEditView; 6.8.2 对于一个能编辑多信息文本格式( RT F )文件的应用程序，选择 CRichEditView(这一 选择将导致应用程序为文档类选择 CRichEditDoc 类); 6.8.3 对于一个图形应用程序，选择 CScrollView; 6.8.4 对于一个简单的监控或帐目管理应用程序，选择 CListView; 6.8.5 要着手创建一个资源管理器类型的应用程序，请选择 CTreeView(在以后的步骤中, 可以手工添加一个 CListView); 6.8.6 在对话框模板外创建一个视图，选择 CFormView(一个对话框是一个被几个控件窗口 占据的窗口，诸如按钮和编辑框); 6.9. MFC 应用程序类型的选择： 6.9.1 如果创建一个用户界面需求有限的应用程序，或如果想界面完全单一，那么就创建 一个对话框应用程序。典型的对话框应用程序包括配置硬件设备的应用程序、屏幕保护程序 和游戏程序等; 对话框要易用且简洁，字体和控件的组织搭配要得体，能简单不复杂，各控件的焦点、 Tab 顺序等要讲究，视应用场合要适当支持键盘。在简洁易用的前提下，力求个性化，设计 得更加友好。程序各对话框的风格要保持一致