IDE设置必须打开设置选项的"要求变量声明","对齐控件到网格","自动缩进"开关。 Tab的宽度统一为4个空格,网格单位一律设为:width 50 height 50。 命名工程ActiveX控件和DLL工程命名格式为(....Lib),EXE工程直接命名,如果是通用组件工程,直接命名,如果是项目或产品工程,则使用项目或产品缩写作为前缀。如:XWY....Lib。 工程命名不必缩写,为了表达意思和用途,可以尽可能地长,而且命名格式采用 (名词) 、 (形容词 + 名词) 或 (名词 + 动作的名词形式)。如:XWYStockOperationLib或XWYStockLib。 (注意:在任何时候,不要使用中文命名,包括文件夹,文件名,函数名,变量名。除非文件需要和用户交互!) 变量变量命名不推荐采用匈牙利命名法,除非命名会和关键字产生冲突的时候,才采用类型缩写+变量实名的匈牙利命名法。一般情况下,变量命名应该简单,尽量使用缩写。 如果是一般的值类型,如integer string,则直接使用变量用途命名,尽量使用全名: Dim name As String Dim count As Interger 对于一般的临时性变量定义,应该尽可能地简单,如: Dim i As Integer For i = 0 to 100 Next I 如果是类对象或自定义类型对象,则在单一使用情况下使用类名称或自定义类型名称的简写来命名: Dim em As EnityManager 如果非单一使用,则使用类型名称缩写为前缀,即使用匈牙利命名法: Dim emRead As EntityManager Dim emSave As EntityManager (注意:所有前缀都全部小写,后面的单词首字母大写) 缩写规则如下: 如果名称由多个单词组成,则取每个单词的首字母,如EntityManager缩写为em,ProcedureManager缩写为pm。 如果名称由一个单词组成,则对单词进行分段取首字母,如Entity缩写为et。 缩写应该控制在3个字母以内,尽量清晰,对于接口名称,I......中的I前缀不对缩写产生任何影响,如Ientity的名称应视作Entity。 除非首字母为元音,否则应该截取辅音做为缩写,如TextBox控件的缩写前缀为txt。 范围标识: 全局变量加前缀:'g_' 模块级变量加前缀:'m_' 过程级变量不加前缀 全局变量和模块级变量应该尽量使用全名称,不推荐使用缩写,如:g_EntityManager 控件控件命名一律使用控件类型缩写+控件用途的命名方式,类型缩写应控制在3个字母以内,缩写规则同变量命名,以下是常用控件的类型缩写,应该严格遵守,如果使用了新的控件,则首先应该在小组内协同一致其类型名称缩写后再进行使用。 cmb Combo box 函数此处函数包括sub和function,以下这两种过程统称为函数。 函数表示的是一个动作,所以它的结构应该是 动词+名词,动词必须小写,后面的名称首字母大写,如: getMaterialCode 函数命名尽量不要使用缩写,而且它的名称应该使人一目了然,能够从名称就知道这个函数的功能,不要使用无意义的函数名称,如:getCode(当这个函数属于Materail类的时候,它还是有意义的),update,readData。 当函数名称不足以表达其功能时,使用在函数头部加上让调用者足够明白的注释。 参数的命名:参数命名的原则是全部小写,如果参数包括两个或以上的单词时,首单词字母小写,其它单词首字母大定,如showCol、isUpdate。 常量常量的命名应该全部大写,使用'_'作为单词间的分隔符,单词尽量使用全名称,如: Public Const MSG_EMPTY_ROW As String = "有空行存在!" 解释: (1) 对一些常用词应该使用简写,如msg (2) 使用Public而不是早期版本的global来声明变量 (3) 对常量的声明必须带上类型,如上面的As String 属性属性的命名采用首字母大写的原则,如ItemCount Item 类、窗体和模块类的命名使用功能名词,不必加任何前缀和后缀,并且单词首字母大写,如:SystemConfig 窗体命名使用功能名词 + Form后缀,如:ListForm。 但对于单据的明细窗体则统一使用Detail后缀替换Form 模块命名:不必加任何前缀和后缀,直接命名 自定义控件自定义控件的命名:名词 + Ctrl 如:EditGridCtrl 格式定义定义的代码块应该放在一起,尽量不要在中间定义变量,变量的定义应该顶行进齐,不能缩进,同时要保证"As"关键字的对齐,如下: Dim i As Integer Dim j As Integer Dim em As EntityManager 对象的定义应该尽可能地带上所属的库名称,防止以后引起名称冲突,如引用了两个Lib,每个中都包含一个stock类,如果不使用As ....Lib.Stock的定义方式,则无法编译通过,为了防止以后程序扩充和修改时引入新的库带来命名冲突,推荐在定义类对象时全部加上库标识,对于本工程的类对象定义也要加上,如: Dim em As ObjectPersistenceLib.EntityManager 空行空行是区分代码块与块的间隔,在函数之间必须加上空行(两行左右),而函数内部,变量声明块和实现块(实现块指除变量声明外的其它代码)要使用空行来间隔(一行),实现块的内部,通过空行来标识一个功能段,如: Private Sub Check(Order As NYSaleBackLib.Order) '* 减少库存 Dim objStockItem As NYStockLib.StockItem Dim objStock As NYStockLib.Stock Dim i As Integer Set objStock = CreateStock() For i = 0 To Order.ItemCount - 1 Set objStockItem = Order.item(i) '* 减少库存 Call objStock.ReduceItem(objStockItem, True) Next i Set objStock = Nothing End Sub (注意:不要使用过多的空行,空行太多影响代码阅读!) 缩进缩进必须严格执行,变量声明块不缩进,实现块必须保证全部缩进(即不可能有实现块是行首对齐的)。 对于基本的控制结构,必须要有缩进,如:IF、DO、WITH、FOR、OPEN、SELECT块,缩进示例如下: ..... If ..... Then ..... End If ..... (注意:在任何地方,不要写ElseIf语句,转换成IF..ELSE..ENDIF结构) 对于过长的语句,必须使用续行,续行位置要有明显意义,示例: sql = "SELECT [code],[name] FROM [Person] " _ & " WHERE [code] LIKE ‘001%' " 函数的参数如果过长,也应该续行,示例: '** '增加库存 '@param ProductCode 产品编号 '@param Spec 长度规格 '@param Color 颜色 '@param Patch 是否拼圈 '@param Volumn 盘号 '@param Ordinal 子库存顺序号 '@param Length 长度 '@param IsCheck 是否审核入库增加(否则为弃审出库增加) Public Sub AddDetail(ProductCode As String, _ Spec As Double, _ Color As String, _ Patch As Boolean, _ Volumn As String, _ Ordinal As Integer, _ Length As Double, _ IsCheck As Boolean) 注释量注释以尽可能少为宜,但必须要做到别人能够通过阅读你的代码明白你的意思,让调用者明白函数功能的表达优先级原则如下: (1) 通过函数名称表达 (2) 通过代码来表达 (3) 通过注释来表达 由上可知,注释是在代码无法充分表达函数功能时才提供,注释同样应该做到准确简洁。 格式注释的格式遵循vbDocMan的写法,一般情况下使用vbDocMan的注释编辑器进行注释编写,对于显而易见的参数或函数功能可以不加注释。参数注释中参数类型可以不要。 示例: '** '读取单据信息 '@param OrderID 单据号 '@param Order 单据 Private Function ReadOrder(OrderID As String, Order As NYSaleBackLib.Order) As Boolean End Function 在每个代码模块(窗体、类、模块、控件)的最上面,必须写上代码编写人(使用英文名或中文拼音缩写)、代码创建时间、代码修改时间和修改说明。 示例: '** '库存修改类 '@writer pureach '@createdate 2003-11-12 '@revision pureach 2003-11-15 '增加对库存修改时同时影响最后入库日期的功能 什么是好的代码(1) 可读性很强的代码格式,能够区分不同的代码块 (2) 清晰明了的命名,在尽可能短的名称长度下传递足够多的信息 (3) 和代码相得益彰的注释(不要让注释重复代码所能表达的信息) (4) 变量的生存期尽可能地短,这样阅读者不用去记大量的变量声明 (5) 使用小函数,将功能复杂的大函数进行分隔 总之,代码的好坏应该让别人是否能够容易读懂来区分,如果对自己的代码不满意,那么先给别人阅读,然后让阅读者告诉你他为什么读不懂,哪些地方读着吃力。好的代码应该能够让你在几个月后回顾自己的代码时一目了然(架构的清晰是代码易读的前提)。 |
|