博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

【智岛软件】程序设计规范

Posted on 2006-07-07 08:56  智岛软件  阅读(675)  评论(0编辑  收藏  举报

程序编码规范V2.0

1     目的... 2

2     概述... 2

3     界面设计... 2

4     命名原则... 2

4.1              常量和变量命名约定    2

4.2              对象命名约定    3

4.3              函数/过程命名约定    4

4.4              通用变量命名    4

5     代码编写... 4

6     程序查错... 5

7     经验总结... 5

 


 

 

1          目的

   规范程序编码,便于维护和合作开发。

2          概述

本文从界面设计、命名原则、代码编写、程序查错、经验总结五个方面作出说明。编程规范是通过总结和反思而养成的信条和习惯。通过这些规范,我们要做到高效率地编程、高质量的代码、高奖金的回报

为什么要进行编码约定

使用统一编码约定的主要原因是,使应用程序的结构和编码风格标准化,以便于阅读和理解这段编码。

好的编码约定可使源代码严谨、可读性强且意义清楚,与其它语言约定相一致,并且尽可能的直观。

3          界面设计

程序应具有以下友好的界面:

ü         操作简便。要站到使用者的角度,尽量使操作简单、易用。如果能一步操作完成,尽量不要让用户操作多步。通常情况下,操作越简单,编程相对要复杂。

ü         外观漂亮。尽量用中国园林设计的审美观点出发,讲究对称、流程,控件的间隔、高宽一致,界面布局要美观(这一点可以参看Office中的界面,希望大家都能提出自己的建议)。

4          命名原则

4.1      常量和变量命名约定

ü         变量应该总是被定义在尽可能小的范围内。

ü         全局 (Public) 变量可以导致极其复杂的状态机构,并且使一个应用程序的逻辑非常难于理解。全局变量也使代码的重用和维护更加困难。所以,全局变量尽量少用。

ü         在我们平台中,变量有以下范围:

范围

声明位置

可用范围

前缀

例子

过程级

过程,子过程或函数过程中

在声明它的过程中

g

gstrUserName

模块级

窗体中。应放窗体代码的最前面声明,前面不要有空格

在声明它的窗体中

dblVelocity

ü         过程和函数尽量只对传递给它们的对象(或变量)进行操作。如果要在过程中使用全局变量,应该在过程起始处的声明部分中标识出来。如果在过程内使用频繁的话,可以声明一局部变量,然后在过程内部使用次局部变量。这样防止不小心修改了全局变量,给编写带来不便。

ü         将变量传递给 Sub 过程及 function 过程,尽量使用ByVal,除非有特殊的功能要求使用 ByRef

部分

描述

ByVal

表示该参数按值传递。

ByRef

表示该参数按引用传递。

ü         对于常量名,应遵循与变量相同的规则。例如:

intUserListMax   '对用户列表的最大限制(整数值,本过程中用)

gstrNewLine     '新行字符(字符串,应用程序全局使用)

ü         声明所有的变量将会节省编程时间,因为键入操作引起的错误减少了。尽量使用Option Explicit 语句要求在程序中必须声明所有的变量。

ü         给变量加前缀来指明它们的数据类型(前缀可以被扩展,用来指明变量范围)。

数据类型

前缀

例子

Boolean

bln

blnFound

Currency

cur

curRevenue

Double

dbl

dblTolerance

Integer

int

intQuantity

Long

lng

lngDistance

String

str

strName

ü         变量名的主体应该使用大小写混合形式,并且应该足够长以描述它的作用。

ü         可以使用标准缩略语以使名称的长度合理化。一般来说,超过 32 个字符的变量名在 VGA 显示器上读起来就困难了。当使用缩略语时,要确保它们在整个应用程序中的一致性。

4.2      对象命名约定

为区分对象和变量,采用有无下划线”_”来标识。变量没有”_”

根据以往排错经验,有一部分的错误就出在这里。例如”Msgbox eb_Name “中,”eb_Name”是对象,执行时,就报错对象不支持此属性或方法。尤其在代码行数很多的情况,思维容易走向盲点,给差错带来不便。如果有了这个分别后,程序员在自己的潜意识中,看到有下划线的,就立刻想到是对象,象上面那种写法就可以避免。 

应该用一致的前缀来命名对象,使读者容易识别对象的类型。下面列出了一些常用的对象约定。

对象类型

中文说明

前缀

例子

Button

按纽

btn

btn_OK

Lable

标签

lbl

lbl_Caption

EditBox

文本框

eb

eb_SchoolName

CheckBox

复选框

chk

chk_IsGoal

Option

收音机按纽

opn

opn_Yes

Combox

下拉框

cmb

cmb_Type

Frame

框架

fra

fra_DosBasic

DBGrid

表格

grd

grd_Main

DateTimeCtrl

日期控件

dtc

dtc_BeginDate

4.3      函数/过程命名约定

ü         描述过程名:过程名的主体应该使用大小写混合形式,并且应该足够长以描述它的作用。而且,函数名应该以一个动词起首,如 InitNameArray CloseDialog

ü         函数(Function)前缀:f  。例如:fChange_Text ()

ü         过程(Sub)前缀:s  。例如: sGrid_Set()

4.4      通用变量命名

ü         返回值: ret 。类型Integer或者Boolean

ü         循环变量: i  j  k 。类型 Integer 

ü         窗体返回值:nCloseType 

ü         SQL字符串:strsql

ü         错误值:strError

ü         调用WebFunction的返回值: strRet

5          代码编写

写代码的时候应注意以下这些内容:

ü         程序员应从编写代码的时侯就开始查错。

ü         程序员在开始编程时就应该考虑代码是否可以共享(或复用),如果是,则应做成可复用性的函数,使其能共用。

ü         程序员应当严格遵守编程规范,以保证效率。

ü         使用一对象前,一定要检查此对象是否已经建立。例如:使用数组前,一定要检查此数据是否存在(IsArray),否则在运行时,如果对象不存在,会有潜在的Bug

ü         保证无错代码:

如果遵守以下原则,则无错代码是可能的:

1 在用法不确定时,查看帮助。

2 数据库操作时,应当加入错误捕获。(以往开发教训中,类似这样的问题带来的后果很多,所以一定要注意)

3 动用编程时,应先理顺思路。(好的思路可能使代码更少,且效率更高。如果思路不清晰,就不要动手,否则越做越乱。这就是谋后而动

4 当一个逻辑单元的程序写好时,及时加上详细的注解,写明逻辑流程。

5 动手编程时,应当考虑,该设计的实现手段易出错的程度如何?如果易出错,则应当找出更好的不易出错的手段再开始写程序。

8)造成错误的一个最普通的原因就是键入了不正确的变量名或把一个控件与另一个控件搞混了。可用 Option Explicit 避免变量名的拼写错误。

9)开始编码时,最好有份详细设计文档,如果没有,一定要自己做份电子草稿,上面写明实现的思路、涉及到的数据表、业务处理要点等。

10)争取每个函数或过程的行数不要超过30行。如果行数多,尽量使用子函数或子过程。因为一般显示下,在30行左右的代码不需要翻页。

11)一旦开始编码,就一鼓作气,力争最快完成。如果半路中断的话,要重新拾起思路,是件费时的事情,或许还找不到当初的灵感:-)

6          程序查错

ü         在编程时,当程序发现错误,应当立即改错。现在就改,以避免程序完成时遗漏未改的错误。

ü         发现错误时,应当找出从错误的源头再修改。(对此,应当摒弃"工作量太大了"的思想)

ü         当代码有错时,绝不可以猜测错在哪里。试图碰运气改正它。必须停下来思考已发现的错误,从而判断是否别的地方有相关的错误还没有暴露出来。思考如何更易发现错误,如何避免此类错误(这点一定要做到,否则就是无头苍蝇,撞来撞去,还撞不出去,切记……)。

ü         在找到一错误原因后,在修改之前,一定考虑周全。修改了此问题后,会不会影响别的模块?是否会给别的模块带来什么影响?是不是别的模块也要做相应的改变?是不是在其他的窗体中也有类似的问题?…..

7          经验总结

ü         任何程序在编程或制作前应有详细设计文档,保证有了方案后再写代码。

ü         必须利用面向对象的思维方式将项目细分,使其模块化,并将模块作为小的项目看待。这种思维方式对于个人做自己的计划任务时很重要,千万不要一锅端,要一步一步分,越细越好。

ü         如果要实现某一功能,则一定要使其完善,即,送给用户"夹生的",不如只给用户"做熟的"