1、命名工程ActiveX控件和DLL工程命名格式为(.Lib)，EXE工程直接命名，如果是通用组件工程，直接命名，如果是项目或产品工程，则使用项目或产品缩写作为前缀。如：XWY.Lib。工程命名不必缩写，为了表达意思和用途，可以尽可能地长，而且命名格式采用 (名词) 、 (形容词 + 名词) 或 (名词 + 动作的名词形式)。如:XWYStockOperationLib或XWYStockLib。(注意：在任何时候，不要使用中文命名，包括文件夹，文件名，函数名，变量名。除非文件需要和用户交互！)变量变量命名不推荐采用匈牙利命名法，除非命名会和关键字产生冲突的时候，才采用类型缩写+变量实名的匈牙利命
2、名法。一般情况下，变量命名应该简单，尽量使用缩写。如果是类对象或自定义类型对象，则在单一使用情况下使用类名称或自定义类型名称的简写来命名：Dim emAs EnityManager 如果非单一使用，则使用类型名称缩写为前缀，即使用匈牙利命名法：Dim emReadAs EntityManagerDim emSaveAs EntityManager(注意：所有前缀都全部小写，后面的单词首字母大写)缩写规则如下：如果名称由多个单词组成，则取每个单词的首字母，如EntityManager缩写为em,ProcedureManager缩写为pm。如果名称由一个单词组成，则对单词进行分段取首字母，如Ent
3、ity缩写为et。缩写应该控制在3个字母以内，尽量清晰，对于接口名称，I中的I前缀不对缩写产生任何影响，如Ientity的名称应视作Entity。除非首字母为元音，否则应该截取辅音做为缩写，如TextBox控件的缩写前缀为txt。范围标识：全局变量加前缀：g_模块级变量加前缀：m_过程级变量不加前缀全局变量和模块级变量应该尽量使用全名称，不推荐使用缩写，如：g_EntityManager控件控件命名一律使用控件类型缩写+控件用途的命名方式，类型缩写应控制在3个字母以内，缩写规则同变量命名，以下是常用控件的类型缩写，应该严格遵守，如果使用了新的控件，则首先应该在小组内协同一致其类型名称缩写后再进
4、行使用。cmbCombo box chkCheckbox cmd Command button dlgCommon dialog controldtDTPickerDropDateControlenmEnumEditBoxfra Frame frm Form gra Graph grdEditGrid MSHFlexGrid FlexGrid DataGridimgImage ImageList labLabel lnLine lstList box lvListViewmnu Menu control nmNumEditBoxoptOption button picPicture rptRe
5、port sbrScroll bar shpShape spnSpin stStatusBar tbToolBartmrTimer txt TextboxtvTreeView函数此处函数包括sub和function，以下这两种过程统称为函数。函数表示的是一个动作，所以它的结构应该是 动词+名词，动词必须小写，后面的名称首字母大写，如：getMaterialCodeupdateGridreadOrder函数命名尽量不要使用缩写，而且它的名称应该使人一目了然，能够从名称就知道这个函数的功能，不要使用无意义的函数名称，如：getCode(当这个函数属于Materail类的时候，它还是有意义的)，up
6、date，readData。当函数名称不足以表达其功能时，使用在函数头部加上让调用者足够明白的注释。参数的命名：参数命名的原则是全部小写，如果参数包括两个或以上的单词时，首单词字母小写，其它单词首字母大定，如showCol、isUpdate。常量常量的命名应该全部大写，使用_作为单词间的分隔符，单词尽量使用全名称，如：Public Const MSG_EMPTY_ROWAs String = “有空行存在！”解释：（1） 对一些常用词应该使用简写，如msg（2） 使用Public而不是早期版本的global来声明变量（3） 对常量的声明必须带上类型，如上面的As String属性属性的命名采用
7、首字母大写的原则，如ItemCount Item 类、窗体和模块类的命名使用功能名词，不必加任何前缀和后缀，并且单词首字母大写，如：SystemConfig窗体命名使用功能名词 + Form后缀，如：ListForm。 但对于单据的明细窗体则统一使用Detail后缀替换Form模块命名：不必加任何前缀和后缀，直接命名自定义控件自定义控件的命名：名词 + Ctrl如：EditGridCtrl格式定义定义的代码块应该放在一起，尽量不要在中间定义变量，变量的定义应该顶行进齐，不能缩进，同时要保证”As”关键字的对齐，如下：Dim iAs IntegerDim jAs IntegerDim emAs
8、EntityManager对象的定义应该尽可能地带上所属的库名称，防止以后引起名称冲突，如引用了两个Lib，每个中都包含一个stock类，如果不使用As .Lib.Stock的定义方式，则无法编译通过，为了防止以后程序扩充和修改时引入新的库带来命名冲突，推荐在定义类对象时全部加上库标识，对于本工程的类对象定义也要加上，如：Dim emAs ObjectPersistenceLib.EntityManager空行空行是区分代码块与块的间隔，在函数之间必须加上空行（两行左右），而函数内部，变量声明块和实现块（实现块指除变量声明外的其它代码）要使用空行来间隔（一行），实现块的内部，通过空行来标识一个
9、功能段，如：Private Sub Check(Order As NYSaleBackLib.Order)* 减少库存Dim objStockItem As NYStockLib.StockItemDim objStock As NYStockLib.StockDim i As Integer Set objStock = CreateStock() For i = 0 To Order.ItemCount - 1 Set objStockItem = Order.item(i) * 减少库存 Call objStock.ReduceItem(objStockItem, True) Next
10、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 cod
11、e 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
12、String, _ Ordinal As Integer, _ Length As Double, _ IsCheck As Boolean)注释量注释以尽可能少为宜，但必须要做到别人能够通过阅读你的代码明白你的意思，让调用者明白函数功能的表达优先级原则如下：（1） 通过函数名称表达（2） 通过代码来表达（3） 通过注释来表达由上可知，注释是在代码无法充分表达函数功能时才提供，注释同样应该做到准确简洁。格式注释的格式遵循vbDocMan的写法，一般情况下使用vbDocMan的注释编辑器进行注释编写，对于显而易见的参数或函数功能可以不加注释。参数注释中参数类型可以不要。示例：*读取单据信息par
13、am OrderID 单据号param Order 单据Private Function ReadOrder(OrderID As String, Order As NYSaleBackLib.Order) As BooleanEnd Function在每个代码模块（窗体、类、模块、控件）的最上面，必须写上代码编写人（使用英文名或中文拼音缩写）、代码创建时间、代码修改时间和修改说明。示例：*库存修改类writerpureachcreatedate 2003-11-12revisionpureach2003-11-15增加对库存修改时同时影响最后入库日期的功能什么是好的代码（1） 可读性很强的代码格式，能够区分不同的代码块（2） 清晰明了的命名，在尽可能短的名称长度下传递足够多的信息（3） 和代码相得益彰的注释（不要让注释重复代码所能表达的信息）（4） 变量的生存期尽可能地短，这样阅读者不用去记大量的变量声明（5） 使用小函数，将功能复杂的大函数进行分隔总之，代码的好坏应该让别人是否能够容易读懂来区分，如果对自己的代码不满意，那么先给别人阅读，然后让阅读者告诉你他为什么读不懂，哪些地方读着吃力。好的代码应该能够让你在几个月后回顾自己的代码时一目了然（架构的清晰是代码易读的前提）。
