Delphi语言规范Word文件下载.docx
《Delphi语言规范Word文件下载.docx》由会员分享，可在线阅读，更多相关《Delphi语言规范Word文件下载.docx（32页珍藏版）》请在冰点文库上搜索。
5.1通用代码风格5
5.2面向对象的PASCAL代码规范5
5.2.1括号5
5.2.2保留字5
5.2.3函数或过程5
5.2.4变量6
5.2.5类型7
5.2.6语句8
5.2.7注释8
5.2.8异常处理9
5.2.9断言10
5.2.10面向对象类10
5.3文件11
5.3.1目录名11
5.3.2文件名11
5.3.3代码单元文件11
5.3.4窗口文件11
5.4控件（Components）12
5.4.1用户自定义控件12
5.4.2控件实例命名规范12
5.4.3标准控件前缀13
1.范围
无。
2.工具
无
3.原则
针对用户而言，界面设计应当遵循以下原则：
●简单易用
这是用户界面设计最重要的也是最基本的目标。
包括：
界面元素应当易于理解，操作简便，自动化程度高，拥有HELP帮助功能以帮助用户理解界面元素的含义、功能和使用方法等等。
●可靠性
用户界面的可靠性是指无故障使用的间隔时间。
用户界面应能保证用户正确、可靠地使用系统，保证有关程序和数据的安全。
●风格一致性
在用户界面设计中，一致的外观与感觉可以在应用程序中创造一种和谐，任何东西看上去都那么协调。
如果界面缺乏一致性，则很可能引起混淆，并使应用程序看起来非常混乱、没有条理、价值降低，甚至可能引起对应用程序可靠性的怀疑。
●美观
在保证界面简单易用和可靠性的前提下，应尽量做到使界面美观，使用户使用时能有一种视觉上的享受，这一条是和界面的风格一致性相辅相成的。
针对公司内部而言，界面设计应当遵循以下原则：
●程序代码的可读性
程序员在编写程序时，应当意识到今后会有人反复阅读这个程序，并沿着自己的思路去理解程序的功能，所以应当注意程序代码的可读性。
●易于本地化
在设计时就考虑到将来本地化的问题将极大的减轻将来软件本地化时的工作量，同时避免将来本地化时降低软件的可靠性。
4.
界面设计规范
4.1界面元素
各界面元素的属性除下面特别说明以外，均必须采用缺省设置。
界面上的所有文本在本地化时都要转换成相应语言的文字，因此设计包含文字的界面元素时应考虑到将来转换后长度会有变化而需留下足够的空间。
若界面中用到了位图等元素，尽量不要在其中包含文本，若必须包含文本，可在位图上放置具有透明背景的文本标签来解决。
4.1.1字体（Font）
中文采用9点阵的宋体，英文采用8点阵的MSSansSerif，颜色采用缺省颜色。
4.1.2窗口（Form）
●尺寸（Width，Height）：
长宽比例在4/3和5/3之间。
●标题（Caption）：
一定要有，其描述应为功能性描述，其中不包含“某某交换机”字样。
●边框样式（BorderStyle）：
除了主窗口以外，其他窗口一般采用对话框样式（bsDialog），若要采用可变尺寸（bsSizeable）边框，必须保证窗口大小改变时，窗口中各界面元素能自动按比例进行缩放。
●图标（Icon）：
对于边框类型为bsSingle和bsSizeable的窗口都有图标，一般情况下将缺省采用应用程序图标（统一网管的图标将请专人设计），若需特别设置，要求图标能反映窗口的功能，且不能使用Delphi缺省的图标。
图标的大小一般为32╳32，16色
●右上角功能按钮（BorderIcons）：
一般应有关闭按钮。
若有最大化按纽，也应该保证窗口最大化时，窗口中各界面元素能自动按比例进行缩放。
●颜色（Color）：
窗口及窗口中控件的颜色一般都采用缺省颜色，特殊情况下若要使用其他颜色，则要考虑到将来本地化时是否符合别的国家或地区的文化特征。
●位置（Position）：
窗口第一次显示时一般应置于屏幕的中央（psScreenCenter），主窗口最大化时的情况例外。
●按钮：
对于对话框，必须有“确定”按钮，对于具有设置功能的对话框，应提供“取消”按钮。
对于复杂的窗口，若界面元素难于理解，还应提供“帮助”按钮。
●创建：
除主窗口属于自动创建（即在应用程序运行之前创建），其他窗口一般应在使用时创建，并在使用完后关闭并释放内存。
4.1.3消息框
●函数：
统一使用Application.MessageBox函数。
●标题：
应在“警告”“错误”“提示”“询问”之中选择，其他均不可用。
●图标：
应与相应的标题相对映，使用Windows提供的缺省图标（MB_ICONWARNING，MB_ICONERROR，MB_ICONINFORMATION，MB_ICONQUESTION）。
可根据标题及消息内容进行选择组合，并注意三者之间的一致性
●使用：
增加，修改，退出动作一般不需要提示（在此动作对所操作的系统有较大的影响时，一般应增加提示）。
删除动作一般要有提示。
4.1.4按钮
●控件使用：
均采用TButton控件，不赞成使用TBitBtn控件。
●高度：
使用缺省高度（25）。
●宽度：
一般使用缺省宽度（75），若标题（Caption）较长，则可适当变宽，一般在标题与按钮边框之间至少应留出5个以上的像素空间。
出于方便阅读的考虑，一组按钮的宽度应保持一致，但如果为了保持这种一致性而导致一系列按钮要求占据大量的空间，则可以只让其中的一个按钮显得比其他按钮大。
●加速键：
除“确定”和“取消”按钮外，所有按钮应有英文大写的加速键，加速键在文字的右方，用小括号括起；
“确定”按钮的加速键为回车键（属性Default=True），“取消”按钮的加速键为ESCAPE键（属性Cancel=True）。
●位置：
一个界面上的按钮应尽量在此界面的右下方（按钮横向排列）或右上方（按钮纵向排列）。
当此界面包含数个逻辑功能块时，各逻辑功能块之间的按钮位置应尽量保持一致。
4.1.5状态条
除了主窗口外，其他窗口一般不应有状态条。
如有必要，应满足如下标准：
●尺寸：
高度应使用Delphi提供的缺省高度。
宽度应随窗口大小调整。
●状态条应在不同的“功能区段”显示不同的信息。
●状态条上的状态信息应随状态的变化而变化（不需显示状态时，应及时的把上面的消息清空）。
4.1.6菜单
除了主窗口外，其他窗口不应有主菜单，各菜单项必须有加速键，加速键在文字的右方，用小括号括起，对于界面上显示的各管理实体，如节点、网元、机架、机框、板位等，可使用右键弹出式菜单以方便操作。
但弹出式菜单中的各项都必须在主菜单中对对应的菜单项。
4.1.7关于Tab键
界面上的操作要素都应该有Tab停驻点，停驻点的顺序应满足：
在一个逻辑操作单位内由上到下，由左到右。
4.2界面布局
在通常情况下，应该按照信息正常阅读时所采用的规范来进行应用程序的界面布局，即从左到右，从上到下，而且把最重要的信息放置在窗口的左上角处。
4.2.1分组和间隔
对于相关的界面元素，应采用分组来处理，这可以通过分组框控件（TGroupBox）或间隔技术来实现这个要求。
对于单选按钮，要求使用TRadioGroup控件，不赞成使用TRadioButton进行组合。
在窗口边界和界面元素之间，应留出一致的边缘，即10个像素点。
在每一个控件之间的间隔一般留出5个像素单位。
4.2.2排列
按用户操作此界面的顺序把控件由上到下，由左到右排列。
不同的控件组之间应尽量对齐。
整个界面应量匀称，不应出现左右或上下严重不均匀现象。
如果信息是垂直布置的，那么就按照它们的左边界（左对齐方式）对区域进行排列。
正文标签通常按照左边进行排列，并且通常放置于它们应用的区域的上方或左方。
如果把正文标签放置于正文框控件的左边，那么就需要显示于正文框中的正文一起对正文的高度进行排列
4.2.3位置
对于一个二级窗口中的主要命令按钮来说，应该把它们放置于右上角中，或者沿着底部的一行进行放置。
如果定义了一个缺省的按钮，那么通常就是集合中的第一个按钮。
“确定”和“取消”按钮应该并排放置在一起。
最后一个按钮应该是“帮助”按钮（如果支持的话）。
如果没有“确定”按钮，但是有其他的命令按钮，则应该把“取消”按钮放置于一系列活动按钮的末端，但是“帮助”按钮之前。
如果一个特定的按钮只能应用于一个特定的区域，那么就把这个按钮置于那个区域之内。
5.
代码编程规范
5.1通用代码风格
一般来说，任何编程风格的目标都是清晰易懂，编码清晰化中最关键的一条就是保持一致性，无论使用什么风格，都要保证在整个项目中始终如一。
●缩排
代码的每级缩进为2个空格，由于制表符在不同的编辑器中的间隔不同，因此禁止在源代码中保存Tab制表符。
●空格
各词法单位之间使用一个空格以增强程序的可读性，如a:
=b应写成a:
=b
●页边界
一般源代码每行的字符数不得超过80，除非只剩下一个单词。
如一行源代码超过了80个字符，可在逗号和操作符后面开始换行，并相对第一行缩进2个空格。
●begin和end
一般来讲，begin应独占一行，如下所示：
fori:
=0to10do
begin
…;
end;
下面这种情况例外，即begin出现在else语句之后：
ifsomestatementthen
end
elsebegin
end语句则总是独占一行。
5.2面向对象的PASCAL代码规范
5.2.1括号
●在开始括号“（”与下一个字符之间不允许插入空格，同样，在结束括号“）”与前一个字符之间也不允许插入空格，如下所示：
CloseProc（AParameter）;
//错误
CloseProc（AParameter）;
//正确
●在语句中不要插入多余的括号，括号只允许出现在必需的地方，如下所示：
if（I=42）then//错误，多余的括号
if（I=42）or（j=42）then//正确，括号必需
5.2.2保留字
Delphi的保留字（在DELPHI编辑器中将以特殊颜色显示）总是全部小写。
5.2.3函数或过程
●通用规范
Ø
函数体内不能有不可到达的代码（inaccessiblecode）
不提倡函数的递归调用
函数的嵌套深度限制在5级以内，以增加程序的可读性，并减少出错的危险
调用具有返回值的函数时，必须判断返回的结果，并根据返回值作相应处理
申明过的函数必须被使用，以防止引起错误
不建议使用数组函数或函数数组。
源文件中必须有被调用函数的显示的函数原型说明
●命名
总是以大写字母开头，并总是采用大小写结合的方式，每个单词的开头采用大写，其余采用小写。
函数或过程名必需与它的内容相关。
对于将产生一个动作的函数或过程一般以动词开头，如：
procedureFormatHardDrive;
对于用来设置参数值的过程一般以Set开头，如：
procedureSetUserName;
对于用来取值的函数一般以Get开头，如：
functionGetUserName:
string;
●参数
函数的所有参数都应该在函数体内被使用，以减少错误
全局变量不能作为函数的参数
格式
对于相同类型的参数一般要求放在一起，如：
procedureFoo（AParam1,AParam2,AParam3:
Integer;
AParam4:
string）;
命名
参数名一般应与它的用途相对应，且以前缀A开头，如：
procedureSomeProc（AUserName:
AUserAge:
Integer）;
参数个数
函数的参数个数一般应少于5个，以提高程序的可读性。
函数的参数表中所有参数的总长度不能大于40个字节，一些自定义的结构参量可以采用传递指针的方式进行参数传递，这样可以减少函数调用对系统堆栈的需求，同时防止因堆栈溢出引起的软件故障。
参数顺序
使用频率高的参数放在使用频率低的参数左边
输入参数放在输出参数的左边
较通用的参数放在较不通用的参数左边
特殊情况：
通常事件处理过程中的TObject类型的参数Sender，通常放在第一个参数的位置
常量参数
若record，array，ShortString或者是interface类型的参数在函数或过程中不改变其值，应将其标识为const类型，这将提高程序的效率。
其他类型的参数也提倡这样做，虽无助于提高程序的效率，但有助于调用者对参数的理解。
参数名冲突
若使用的函数或过程在两个代码单元中都存在，则实际调用的函数或过程将是在uses语句中显示在后面的单元中的函数或过程，为避免这种混淆，一般在该函数或过程前面加上代码单元的名字，如：
SysUtils.FindClose（SR）;
或
Windows.FindClose（Handle）;
5.2.4变量
●变量名应能反映它的用途。
●申明过的变量必须被使用，没有被使用的变量应从程序中删除，以提高代码的可读性和可靠性。
●每行只能定义一个变量。
●变量申明与初始化尽量在一起。
●常量名一般以小写前缀cnst开头，各单词之间以大写字母分隔，如cnstCompanyName。
源文件里不能出现无意义的数字，所有数字都用常量代替。
这样，一方面可以提高程序的可读性，另一方面有利于程序的维护。
特殊情况例外。
●变量名一般以代表该变量类型的小写前缀开头，各单词之间以大写字母分隔。
常用类型前缀列表如下：
i：
Integer
f：
Single,Double
c：
Char
p：
Pointer
b：
Boolean
uc：
Byte
w：
Word
dw：
LongWord
a：
数组，ArrayofTYPE
s：
String
以上前缀可以进一步组合成新的类型，自定义的数据类型可以自己规定类型前缀，如果该类型使用较为广泛，可以升级为公司内部的通用前缀。
目前已有的内部通用前缀为：
pid：
PID变量
●循环变量一般用i，j，k，…来表示，也可以用更有意义的单词来表示，如UserIndex。
对于嵌套的循环，一般最外层循环用i，第二层用j，依此类推。
●全局变量
一般不赞成使用全局变量，除非必要。
对于只在一个单元中使用的全局变量（又称模块内静态变量）必需放在implementation部分中定义。
全局变量必须加上表示变量活动范围的前缀，并以下划线分隔，模块内静态变量加m_，如m_pReleaseIn，供几个单元共用的全局变量前加mm_，如mm_sName；
必须记住的是：
全局变量在var部分中申明时就已经自动初始化为0值（0，nil，Unassigned）。
除非要初始化的值与之不同，否则不要再显式的进行初始化，因为显式的初始化将增加磁盘上exe文件的大小。
5.2.5类型
●大小写约定
若类型名为Delphi保留字，则必须全部小写。
其他类型则以大写开头。
WIN32API的类型通常采用全部大写，Delphi程序也将遵循这一习惯，若用到WIN32API中的类型，则采用全部大写。
举例如下：
var
sName:
//保留字
hwndMain:
HWND;
//WIN32API类型
i:
//在System模块中定义的类型
●浮点类型
不赞成采用Real表示浮点类型，Real是为了与老版本的PASCAL兼容才保留下来的。
一般采用Double表示浮点类型，且Double为IEEE规定的标准数据类型，CPU和总线一般也是针对Double类型进行优化。
除非浮点数超过了Double能表达的范围才使用Extened，因为Extended是Intel定义的类型，在Java中不支持。
●枚举类型
枚举类型名一般以大写字母T打头
枚举类型的枚举值名必须用表示枚举类型名缩写的2到3个小写字母作为前缀，如：
TSongType=（stRock,stClassical,stCountry,stAlternative,stHeavyMetal,stRB）;
●可变类型
可变类型一般不鼓励使用，除非变量类型只能在运行时确定，如COM程序等。
●结构类型
结构类型（包括数组类型和纪录类型）一般以大写字母T打头，若声明了指针类型，必须以前缀P打头，且在类型定义之前声明，如：
type
PCycleArray=^TCycleArray;
TCycleArray=array[1..100]ofInteger;
PEmployee=^TEmployee;
TEmployee=record
EmployeeName:
EmployeeRate:
Double;
5.2.6语句
●通用规则
每行只允许一条语句。
逻辑语句块（if,else,for,do,while,case）的嵌套深度一般不超过3级，以增加程序的可读性。
在单个if、while等判断语句中，不能有多于三个条件测试部分，且各测试部分必须使用括号括起来，如应if（iParaA=iParaBand（iParaB=iParaC）and（iParaC=iParaD）then。
●goto语句
不允许使用goto语句，尤其是局部goto语句，以免破坏程序的模块化结构，降低程序的可读性，甚至会带来一些逻辑错误
●if语句
在多重条件判断时，尽量把简短的判断放在前面，复杂的判断放在后面，提高代码的执行效率
最有可能发生的执行情况应该放在if/then/else语句的then子句中，较少可能发生的执行情况应该放在else子句中。
尽可能地用case语句代替链条似的if语句（即if/elseif/elseif/…/else）。
if语句内不能有赋值语句，如（ifx:
=y），这类语句不够明确，容易引起混淆
●case语句
case语句的分支按数字顺序或字母顺序排列
case语句内的else分支不能被省略，以用于合法的缺省值或检测错误。
case语句的每个分支里的语句数一般应少于30行，且应使用begin，end将自己与其它分支隔开，以提高程序的可读性。
●循环语句（for，while，repeat）
对于循环次数已经确定的必须使用for语句
所有为循环语句所写的初始化代码必须直接放在循环语句的前面，不允许中间有不相关的代码。
for循环语句内的计数器不能在循环体内被修改，同时，它必须是局部变量，这样将减少出错的危险，并提高程序的可读性
●with语句
对于with语句的使用应该谨慎，不允许在with语句中出现多个对象或结构，既不允许以下这种情况出现：
withRecord1,Record2do
这种情况很容易让程序员感到混乱，且容易造成难以检测的错误。
5.2.7注释
●注释行不得少于程序行的20%。
●程序中关键的地方需增加注释，以提高程序的可读性。
●所有的源代码文件都必须增加文件头注释，文件头注释格式如下：
{***************************************************************************}
{ModuleName:
Main}
{FileName:
Main.pas}
{Author:
yuyong}
{Version:
1.0}
{Date:
1999.9.1}
{Seeto:
}
{ModifiedRecord}
{DateVersionModifiedbyComment}
{1999.9.11.0yuyongCreated}
●每个函数/过程必须增加函数头注释，函数头注释格式如下：
{Name:
GetUserData（varAUserName:
String;
varAUserID:
Integer）}
{Function:
Gettheusernameanduserid}
{Paras}
{AUserName--UserName}
{AUserId--UserId}
{GlobalVars}
{Return:
ModalResult}
{Author/Date:
yuyong/1999.9.1}
●在程序逻辑块的begin号后要有至少一行注释，以提高程序的可读性，有利于软件的维护。
●在超过三层以上的嵌套语句中，每一个end后都应该加上注释，以表明对应的哪一层的逻辑语句块
5.2.8异常处理
异常处理必须在程序中极大限度的使用以检测错误和保护资源，这就是说，在所有有资源分配的地方，就必须用到try…finally以确保资源被释放。
只有一种情况例外，就是在单元的initialization部分分配资源而在finalization中释放资源或者在对象的构造函数（constructor）中分配资源而在析构函数（destructor）中释放资源。
●try…finally的使用
只要可能，每一个资源的分配都应该对应一个try…finally结构，例如下面的语句将有可能导致错误：
SomeClass1:
=TSomeClass.Create;
SomeClass2:
升级会员 