（注：以下内容都是作者个人的学习经验和体会，仅代表个人观点。针对Win32下的Delphi程序开发而言，部分内容或思想也可适用于其它工具或平台下的软件开发。） 在程序员的求职资料中，用得最泛滥的词可能是“熟悉”和“精通”。评价一个程序员的综合能力并不容易，下面的文字试图以Delphi程序开发为例定义一种描述程序员开发能力的方法。 一、 学习阶段划分。 根据我个人的经验，Delphi程序设计分为以下几个阶段： 1、 熟悉阶段。 这一阶段指从未接触过Delphi的人，刚开始学习到初步掌握Delphi的语法、可视化编程、面向对象编程的概念、Delphi IDE开发环境、基本代码编写、程序结构的过程。 熟悉阶段结束后，学习者应该可以编写简单的程序，同时对整个Delphi开发环境有一定的了解，但还不能从事开发工作。 根据学习者是否有编写其它语言代码的经验、是否接触过面向对象编程等因素，这一过程可能需要数天到数十天的时间。 2、 入门阶段。 在熟悉Delphi后，入门的标志是学习者可以有目的地利用Delphi强大的可视化开发环境、结合一些常规的代码编写技术，编制一些小型的程序，或是完成简单的数据库应用。同时，还应掌握基本的程序调试方法。 入门后，程序员可以从事简单的开发工作，或担任中小型系统的用户界面设计及简单代码的编写任务。 同样，如果没有代码编写经验，这一过程将需要一个月或更多的时间。 3、 进阶阶段。 相当多的程序员处于进阶阶段，他们通过经常性地开发工作，积累代码编写和程序调试经验，通过各种途径寻找各类代码编写技巧。每个人根据自已从事的工作或兴趣，在某一方面或几个方面大量的实践，可以独立开发小型、技术含量不高的系统，或在大中型系统中负责普通代码的编写。 绝大部分的在职程序员处于这一阶段，如果一个程序员不是有目的地在学习、工作中总结、提高，可能很长时间、数年甚至终生处于这一阶段。 4、 小成阶段。 只有系统地掌握了Delphi的结构体系，从实践上升到理论，有自己完整的编程思想和风格，或是在深度上达到了相当水平、或是在广度上有了相当经验，知识达到融会贯通的地步，才算小有所成。 此时，在代码编写方面，只要有时间，程序员几乎可以实现所有想做的东西。很多功能，都可以举出几种实现方法并从效率、可读上优化选取。 除了Delphi，程序员应该对操作系统有相当深入的了解，能在短时间内学会新的知识并加以应用，可以读懂绝大部分Delphi源码，完成复杂程序的调试。 如果向深度发展，程序员应该可以编写出具有一定水平的组件、专家或较专业的程序。如果向广度发展，则可以完成中小型的开发任务，或是大中型系统中的核心代码编写以及大部分系统分析工作。 这一阶段几乎是没有现成经验可学的，完全靠个人的修行和领悟，小有所成后程序员在软件方面可独挡一面。 5、 大师级。 如果前面四个阶段在某种程度上都可以看做是“应用”的话，大师级的程序员就处于“设计和创造”这一层次。 他们已到技进乎道的境界，可以把Delphi玩得随心所欲，可以创造新的东西，把握发展方向，随手写的代码都可以当教材用。Borland公司的工程师、国外一些著名软件、控件包的作者、以及国内少数程序员属于这一阶段。 二、 代码阅读分析能力。 对一个程序员来说，读懂别人写的代码是一项基本的能力。不仅包括阅读写得好的程序，也包括阅读写得一般甚至低劣的代码。 代码阅读分析又可分为三个层次，一是代码本身的阅读能力，二是代码编写思想的理解能力，三是算法模型分析设计能力。 要看懂一段代码的作用和功能，首先自己应该拥有大量的代码阅读编写经验，然后是从手册资料中快速获得所需信息的能力。然而，仅有这些，很多优秀的代码仍然不易理解，这就需要程序员的宏观分析和联想能力。 和其它所有事物一样，很多代码也只有在特定环境中才有其存在的意义。有经验的程序员在拿到一段代码后并不急于马上阅读，而是在理解代码所在单元甚至工程的功能后再有目的地分析，从宏观（系统框架结构）和微观（具体代码）上分析作者的设计意图、框架结构、实现方法，从中汲取经验或对代码编写质量进行评估。 再深入一些， 是代码和软件的算法设计。给你一段DES加密算法、UCL压缩算法或MCNN多层分组神经网络的实现代码，如果你没有相关的理论知识做基础，即使有源算法模型也是无法看懂的。 三、 代码编写调试能力。 程序设计能力一般指的就是代码编写调试的能力，程序员的代码直接代表了他的编程水平。 1、 代码编写规范。 代码、注释的书写是否规范直接反映出一个程序员对程序设计的态度。不同的组织定义了不同的代码编写规范，但从外观上看，写得好的代码看起来都差不多一个模样，而糟糕的代码则五花八门。 2、 程序框架和算法结构。 很多程序员在一开始编写代码时缺乏对开发目标的细致分析和策划，边写边改，结果写出的代码结构冗长、算法凌乱、可读易维护性差，特别是在多人开发时很容易导致开发中后期进展缓慢甚至陷入僵局。优秀的程序员代码书写简练、算法清晰、结构合理，他们善于利用编译器强大的语法检查功能减少潜在的错误，并在设计编写代码时充分考虑程序的可移植性和升级能力。 3、 软件测试和代码调试能力。 调试复杂代码的能力同样是区分程序员能力的重要因素。同一段有问题的代码，不同的人调试的时间可能相差数倍甚至数十数百倍。特别是组件开发等不可视代码的调试，要求一个没有太多经验的程序员完成是不现实的。而一个优秀的程序员同时也应该是一个优秀的测试员，发现问题的能力和解决问题的能力同样重要，尽管并不是所有人都能认识到这一点。 四、 程序员类型。 从程序员所从事的工作及兴趣来看，可将其简单地划分为： 1、 应用型。 又可分为以“其它领域结合软件开发”为主和以“软件开发结合其它领域”为主两种。 前者有自己的专业知识，但不满足于简单的操作应用，而利用VB、Delphi等开发工具的强大RAD能力开发与自己专业相关的软件。后者的工作是将计算机技术应用于其它领域，主要为企业编写各种基于商业数据库及网络通讯或一些自动化控制应用的软件。 应用型程序员一般是“广度型”发展的，他们并不注重系统底层知识的学习，而重在“应用”，利用开发工具来实现“行业规则”而不需要阅读编写底层、复杂的代码。 2、 技术型。 这一类型的程序员是纯软件技术型的，他们的开发焦点集中在计算机软件本身上，属“深度”发展型。 技术型程序员大多追求完美、吹毛求疵，对他们来说，花上数小时的时间优化一段代码，使程序执行效率提高10%是一件很惬意的事。技术型程序员一般重名重义不重利，喜欢自由，不愿受现有框架的约束，每每有惊人之举，他们大多特立独行或在软件开发中负责核心代码编写，而这个世界也因这些程序员的存在而变得美丽。 3、 创造型。 创造型程序员结合了应用与技术型的特点。 他们既有精明的商业头脑，又有强劲的技术实力，既是管理人才又是技术人才，是炙手可热的人物。关于他们的描述媒体上已有很多，不再赘述。

目录

1、前言 3 2、源程序书写规范 3 2.1通用源代码格式规范 3 2.1.1缩进 3 2.1.2边距 3 2.1.3 Begin…End语句 3 2.1.4注释 4 2.2 OBJECT PASCAL语句格式书写规范与用法 4 2.2.1括号 4 2.2.2保留字和关键字 4 2.2.3过程和函数 5 2.2.4变量 5 2.2.5类型 6 2.2.6语句 6 2.2.7结构化异常处理 7 3命名规范 8 3.1过程(PROCEDURE)与函数(FUNCTION) 8 3.1.1命名 8 3.1.2形参 9 3.1.3命名冲突 9 3.2变量（VARIABLE） 9 3.2.1局部变量 9 3.2.2全局变量 9 3.3类型（TYPE） 9 3.3.1一般类型 9 3.3.2构造类型 10 3.3.3类类型（Class） 10 3.3.4元件类型 11 3.3.5窗体和对话框类型 13 3.3.6数据模块类型 15 3.4文件 16 3.4.1项目文件 16 3.4.2窗体文件 16 3.4.3数据模块文件 16 3.4.4远程数据模块文件 16 3.4.5单元文件 17 4、DELPHI代码自动格式化工具 18

1、前言 本文档主要是为Delphi开发人员提供一个源代码书写标准，以及程序和文件的命名标准，使他们在编程时

有一致格式可遵循。这样，每个编程人员编写的代码能够被其他人理解。 注：本文档不包含用户界面标准。用户界面标准是独立于其他标准的，并且同样是重要的。 2、源程序书写规范 2.1通用源代码格式规范 2.1.1缩进 缩进就是每级间有两个空格。不要在源代码中放置制表符。这是因为，制表符的宽度随着不同的设置和代

码管理实用程序(打印、文档及版本控制等)而不同。 通过使用Tools|Environment 菜单，在Environment Options 对话框的General页上，不要选中Use

Tab Character [...]]]> 目录

1、前言 3
2、源程序书写规范 3
2.1通用源代码格式规范 3
2.1.1缩进 3
2.1.2边距 3
2.1.3 Begin…End语句 3
2.1.4注释 4
2.2 OBJECT PASCAL语句格式书写规范与用法 4
2.2.1括号 4
2.2.2保留字和关键字 4
2.2.3过程和函数 5
2.2.4变量 5
2.2.5类型 6
2.2.6语句 6
2.2.7结构化异常处理 7
3命名规范 8
3.1过程(PROCEDURE)与函数(FUNCTION) 8
3.1.1命名 8
3.1.2形参 9
3.1.3命名冲突 9
3.2变量（VARIABLE） 9
3.2.1局部变量 9
3.2.2全局变量 9
3.3类型（TYPE） 9
3.3.1一般类型 9
3.3.2构造类型 10
3.3.3类类型（Class） 10
3.3.4元件类型 11
3.3.5窗体和对话框类型 13
3.3.6数据模块类型 15
3.4文件 16
3.4.1项目文件 16
3.4.2窗体文件 16
3.4.3数据模块文件 16
3.4.4远程数据模块文件 16
3.4.5单元文件 17
4、DELPHI代码自动格式化工具 18

1、前言
本文档主要是为Delphi开发人员提供一个源代码书写标准，以及程序和文件的命名标准，使他们在编程时

有一致格式可遵循。这样，每个编程人员编写的代码能够被其他人理解。
注：本文档不包含用户界面标准。用户界面标准是独立于其他标准的，并且同样是重要的。
2、源程序书写规范
2.1通用源代码格式规范
2.1.1缩进
缩进就是每级间有两个空格。不要在源代码中放置制表符。这是因为，制表符的宽度随着不同的设置和代

码管理实用程序(打印、文档及版本控制等)而不同。
通过使用Tools|Environment 菜单，在Environment Options 对话框的General页上，不要选中Use

Tab Character 和Optional Fill 复选框，这样，制表符就不会被保存。
2.1.2边距
边距设置为80个字符。源代码一般不会因写一个单词而超过边距，但本规则比较灵活。只要可能，长度超

过一行的语句应当用逗号或运算符换行。换行后，应缩进两个字符。
2.1.3 Begin…End语句
begin 语句必须单独占一行。例如，下面第一行是错误的，而第二行正确：
for i:=0 to 10 do begin // 错, begin 与f o r 在同一行
for i:=0 to 10 do // 对, begin 在另外一行中
begin
本规则的一个特殊情况是，当begin 为else 语句的一部分时，例如：
if some statement = then
begin
. . .
end
else begin
Some Other Statement;
end;
注意：end 语句总单独一行。当begin 不为else 语句的一部分时，相应的end 语句与begin 语句的缩进

量相同。
2.1.4注释
我们通常使用“{…}”类型的块注释，以前的“(*…*)”类型的块注释用于临时注释掉暂不使用的代码

，从Delphi 2开始支持“//”行注释，如果决定不在支持Delphi 2.0以下的版本，可以使用“//”注释。

2.2 Object Pascal语句格式书写规范与用法
2.2.1括号
在左括号与下一字符之间没有空格。同样，右括号与前一字符也没有空格。下面的例子演示了正确与不正

确的空格。
CallProc( Aparameter ); // 错!
CallProc(Aparameter); // 正确!

不要在语句中包含多余的括号。在源代码中，括号只有在确实需要时才使用。下面的例子演示了正确与不

正确用法：
if (I=42) then // 错，括号是多余的
if (I=42) or (J=42) then // 正确，必须使用括号
2.2.2保留字和关键字
Object Pascal 语言的保留字和关键字总是完全的小写。下面是Delphi 5保留字列表:
and array as asm
begin case class const
constructor destructor dispinterface div
do downto else end
except exports file finalization
finally for function goto
if implementation in inherited
initialization inline interface is
label library mod nil
not object of or
out packed procedure program
property raise record repeat
resourcestring set shl shr
string then threadvar to
try type unit until
uses var while with
xor private protected public
published automated

2.2.3过程和函数
□ 格式
过程名应当以大写字母开始，且大小写交错以增加可读性。下面是一个不正确的写法：
procedure thisisapoorlyformattedroutinename;
改成这样写就对了：
procedure ThisIsMuchMoreReadableRoutineName;

□ 形参
● 格式
只要可能，同一类型的形参应当归并在一起：
procedure Foo(Param1,Param2,Param3:Integer;Param4:string);

● 参数顺序
形参的顺序主要要考虑寄存器调用规则。最常用的参数应当作为第一个参数，按使用频率依次从左到右排

。输入参数位于输出参数之前。范围大的参数应当放在范围小的参数之前。例如：
SomeProc(aPlanet, aContinent, aCountry, aState, aCity).
有些则例外。例如，在事件处理过程中，TObject 类型的Sender 参数往往是第一个要传递的参数

。

● 常量参数
要使记录、数组、短字符串或接口类型的参数不能被过程修改，就应当把形参标以Const 。这样，编译器

将以最有效的方式生成代码，保证传递的参数不可变。 如果其他类型的参数希望不被过程所修改，也可

以标上Const 。尽管这对效率没有影响，但这给过程的调用者带来了更多的信息。

2.2.4变量
□ 局部变量
局部变量用于过程内部，如果需要的话，应当在过程的入口处立即初始化变量。局部的AnsiString 类型

的变量自动被初始化为空字符串，局部的接口和dispinterface类型的变量自动被初始化为nil，局部的

Variant和OleVariant类型的变量自动被初始化为Unassigned。

□ 全局变量
一般不鼓励使用全局变量。不过，有时候需要用到。即使如此，也应当把全局变量限制在需要的环境中。

例如，一个全局变量可能只在单元的实现部分是全局的。
全局变量如果将由许多单元使用，就应移动到一个公用单元里被所有对象使用。全局变量可在声明时

直接初始化为一个值。注意，所有全局变量自动进行零初始化，因此，不要将全局变量初始化为诸如0 、

nil、或Unassigned等空值。零初始化的全局变量在.EXE文件中不占空间。零初始化的数据保存在虚拟的

数据段中，而虚拟数据段只在应用程序启动时才分配内存。非零初始化的全局数据则在.EXE文件中占空间

。

2.2.5类型
□ 大小写规则
类型标识符是保留字，应当全部小写。Win32 API 类型常常全部大写，并且遵循诸如Windows.pas或其他

API单元中关于特定类型名的规则。对于其他变量名，第一个字母应大写，其他字母则大小写交错。下面

是一些例子：
var
MyString: string; // 保留字
WindowsHandle: HWND; // Win32 API 类型
I: Integer; //在System单元中引入的类型标识

□ 浮点型
不鼓励使用Real类型，因为它只是为了与老的Pascal代码兼容而保留的。通常情况下，对于浮点数应当使

用Double。Double可被处理器优化，是IEEE定义的标准的数据格式。当需要比Double提供的范围更大时，

可以使用Extend。Extend是intel专用的类型，Java不支持。当浮点变量的物理字节数很重要时(可能使用

其他语言编写DLL)，则应当使用Single。

□ Variant和OleVariant
一般不建议使用Variant和OleVariant。但是，当数据类型只有在运行期才知道时(常常是在COM和数据库

应用的程序中)，这两个类型对编程就有必要。当进行诸如自动化ActiveX控件的COM编程时，应当使用

OleVariant；而对于非COM编程，则应当使用Variant。这是因为，Variant能够有效地保存Delphi的原生

字符串，而OleVariant则将所有字符串转换为OLE字符串(即WideChar字符串)，且没有引用计数功能。

2.2.6语句
□ IF语句
在if/then/else语句中，最有可能执行的情况应放在then子句中，不太可能的情况放在else子句中。为了

避免出现许多if语句，可以使用case语句代替。如果多于5级，不要使用if语句。请改用更清楚的方法。

不要在if语句中使用多余的括号。
如果在if语句中有多个条件要测试，应按照计算的复杂程度从右向左排。这样，可以使代码充分利用

编译器的短路估算逻辑。例如，如果Condition1比Condition2快，Condition2比Condition3快，则if语句

一般应这样构造：
if Condition1 and Condition2 and Condition3 then
如果Condition3为False的机会很大，利用短路估算逻辑，我们也可以将Condition3放在最前面：if

Condition3 and Condition1 and Condition2 then

□ Case语句
case语句中每种情况的常量应当按数字或字母的顺序排列。每种情况的动作语句应当简短且通常不超过4

- 5 行代码。如果动作太复杂，应将代码单独放在一个过程或函数中。Case语句的else子句只用于默认情

况或错误检测。
case语句遵循一般的缩进和命名规则。

□ While语句
建议不要使用Exit过程来退出while循环。如果需要的话，应当使用循环条件退出循环。所有对while循环

进行初始化的代码应当位于while入口前，且不要被无关的语句隔开。任何业务的辅助工作都应在循环后

立即进行。

□ For语句
如果循环次数是确定的，应当用for语句代替while语句。

□ Repeat语句
repeat语句类似于while循环，且遵循同样的规则。

□ With语句
with语句应小心使用。要避免过度使用with语句，尤其是在with语句中使用多个对象或记录。例如：with

Record1,Record2 do这些情况很容易迷惑编程人员，且导致调试困难。
with语句也遵循本章关于命名和缩进的规则。

2.2.7结构化异常处理
□ 概述
异常处理主要用于纠正错误和保护资源。这意味着，凡是分配资源的地方，都必须使用try…finally来

保证资源得到释放。不过，如果是在单元的初始/结束部分或者对象的构造器/析构器中来分配/释放资源

则例外。

□ try…finally的用法
在可能的情况下，每个资源分配应当与try…finally结构匹配，例如，下面代码可能导致错误：
SomeClass1 := TSomeClass.Create;
SomeClass2 := TSomeClass.Create;
Try
{ do some code }
finally
SomeClass1.Free;
SomeClass2.Free;
end;
上述资源分配的一个安全方案是：
SomeClass1 := TSomeClass.Create;
Try
SomeClass2 := TSomeClass.Create;
Try
{ do some code }
finally
SomeClass2.Free;
end;
finally
SomeClass1.Free;
end;

□ try…except的用法
如果你希望在发生异常时执行一些任务，可以使用try…except。通常，没有必要为了简单地显示一个错

误信息而使用try…except，因为Application对象能够自动根据上下文做到这一点。如果要在子句中激

活默认的异常处理，可以再次触发异常。

□ try…except…else的用法
不鼓励使用带else子句的try…except，因为这将阻塞所有的异常，包括你没有准备处理的异常。

3命名规范
3.1过程(Procedure)与函数(Function)
3.1.1命名
过程与函数名应当有意义。进行一个动作的过程最好在名称前加上表示动作的动词为前缀。例如：
procedure FormatHardDrive;
设置输入参数值的过程名应当以Set 为其前缀，例如：
procedure SetUserName;
获取数值的过程名应当以Get 为其前缀，例如：
function GetUserName:string;

3.1.2形参
所有形参的名称都应当表达出它的用途。如果合适的话，形参的名称最好以字母a 为前缀，例如：
procedure SomeProc(aUserName:string; aUserAge:integer);
当参数名与类的特性或字段同名时，前缀a 就有必要了。

3.1.3命名冲突
当两个单元中含有相同名称的过程时，如果调用该过程，实际被调用的是Uses 子句中较后出现的那个单

元中的过程。为避免这种情况，可在方法名前加想要的单元名，例如：
SysUtils.FindClose(SR);或Windows.FindClose(Handle);

3.2变量（Variable）
变量的名称应当能够表达出它的用途。循环控制变量常常为单个字母，诸如I 、J 或K 。也可以使用更有

意义的名称，例如UserIndex。布尔变量名必须能清楚表示出True 和False 值的意义。
3.2.1局部变量
局部变量遵循其他变量的命名规则。

3.2.2全局变量
全局变量以大写字母“G”打头，并遵循其他变量的命名规则。

3.3类型（Type）
3.3.1一般类型
枚举类型名必须代表枚举的用途。名称前要加T字符作为前缀，表示这是个数据类型。枚举类型的标识符

列表的前缀应包含2 – 3 个小写字符，来彼此关联。
例如：
TSongType=(stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);
枚举类型的变量实例的名称与类型相同，但没有前缀T ，也可以给变量一个更加特殊名称，诸如：

FavoriteSongTypel、FavoriteSongType2等等。
3.3.2构造类型
□ 数组类型
数组类型名应表达出该数组的用途。类型名必须加字母“T”为前缀。如果要声明一个指向数组类型的指

针，则必须加字母P 为前缀，且声明在类型声明之前。例如：
type
PCycleArray = ^TCycleArray;
TCycleArray=array[1..100] of integer;
实际上，数组类型的变量实例与类型名称相同，但没有“T”前缀。

□ 记录类型
记录类型名应表达出记录的用途。类型名必须加字母T为前缀。如果要声明一个指向记录类型的指计，则

必须加字母P为前缀，且其声明在类型声明之前。例如：
type
PEmployee = ^TEmployee;
TEmployee = record
EmployeeName: string;
EmployeeRate: Double;
end;

3.3.3类类型（Class）
□ 命名与格式
类的名称应当表达出类的用途。一般的类名前要加字母“T”，如果是接口类那么类名前要加“I”，错误

异常类的类名前要加“E”，而类引用类型（Class-reference type）则要在类名后加“Class”。例如：
type
TCustomer = class(TObject);
ICustomer = interface;
TCustomerClass = class of TCustomer
ECustomerException = class(Exception);
类的实例名称通常与类名相同，只不过没有前缀“T”。
var
Customer: TCustomer;
注意:关于元件的命名，请参阅“元件类型”。

□ 字段
● 命名与格式
字段的命名遵循与变量相同的规则，只不过要加前缀F ，表示这是字段。

● 可见性
所有字段必须为私有。如果要在类的作用域之外访问字段，可借助于类的属性来实现。

□ 方法
● 命名与格式
方法的命名遵循与过程和函数相同的规则。

● 静态方法
当你不希望一个方法被派生类覆盖时，应当使用静态方法。

● 虚拟方法（Virtual）与动态方法（Dynamic）
当你希望一个方法能被派生类覆盖，应当使用虚拟方法(virtual)。如果类的方法要被多个派生类直接或

间接地使用，则应当用动态方法(dynamic)。例如，某一个类含有一个被频繁覆盖的方法，并有100个派生

类，则应将方法定义为动态的，这样可以减少内存的开销。

● 抽象方法（Abstract）
如果一个类要创建实例，则不要使用抽象方法。抽象方法只能在那些从不创建实例的基类中使用。

● 属性访问方法
所有属性访问方法应当定义在类的私有或保护部分。属性访问方法遵循与过程和函数相同的规则

。用于读的方法应当加“Get”前缀，用于写的方法应当加“Set”前缀，并且有一个叫Value的参数，其

类型与属性的类型相同。例如：
TSomeClass = class(TObject)
private
FSomeField: Integer;
protected
function GetSomeField: Integer;
procedure SetSomeField(Value: Integer);
public
property SomeField: Integer read GetSomeField write SetSomeField;
end;
尽管不是必须，但还是建议你使用写访问方法来访问代表私有字段属性。

□ 属性
属性作为私有字段的访问器，遵循与字段相同的命名规则，只不过没有F前缀。属性名应为名词，而不是

动词。属性是数据，而方法是动作。数组属性名应当是复数，而一般的属性应当是单数。

3.3.4元件类型
□ 元件类型的命名标准
元件的命名与类的命名类似，只不过当它与其它元件名称冲突时，你可以加上3个字符的前缀，用以标识

公司、个人或其他实体。例如，一个时钟元件可以这样声明：
TddgClock = class(TComponent)
注意：作为前缀的3 个字符要小写。

□ 元件实例的命名规则
元件实例的名称应当能够描述其实际意义，这里命名规则使用了一个变更的匈牙利前缀命名规范。使用前

缀而不使用后缀的原因是在搜寻时，在对象检查器和代码探索器中搜寻构件的名字比搜寻构件的类型更容

易。在这个标准中，元件实例名包括两个部分：前缀和性质标识名。
● 元件的前缀
元件的前缀多是表现元件类型的字母缩写。参见下面表中的元件前缀：

元件类名 元件前缀
TActionList, TAction表示动作的列表项 act
TButton, TSpeedButton, TBitBtn等所有的按钮类 btn
TCheckBox, TDBCheckBox等所有的检查框 chk
TRadioButton单选按钮类 rdo
TToolBar工具条 tb
TMainMenu所有的主菜单类 mm
TMainMenuItem所有的菜单项类 mi
TPopupMenu所有的弹出式菜单类 pm
TPopupMenuItem所有的弹出式菜单项类 pmi
TLabel, TStaticText等所有用来显示的标签类 lbl
TPanel等所有的面板类 pnl
TPageControl等所有的页式控件类 pgc
TEdit, TMaskEdit等所有的单行编辑框类 edt
TMemo, TRichEdit等所有的多行编辑框类 mmo
TDrawGrid, TStringGrid等所有的网格类 grd
TAnimate等所有的动画类 ani
TImageList等所有的图片列表类 il
TImage等图片类 img
TChart图表类 cht
TComboBox, TDBComboBox等所有的下拉式列表框类 cbo
TListBox, TDBList等所有的列表框类 lst
TTreeView tv
TListView lv
THotKey hk
TSplitter等所有的分隔符类 spt
TOpenDialog等所有的对话框元件类 dlg
TTable等所有的数据表类 tbl
TQuery等所有的SQL查询类元件 qry
TClientDataSet所有的客户数据集元件 cds
TDataSource ds
TDatabase db
TSockConnection,TDCOMConnection等连接元件类 con
TQuickRep, TFastReport等所有的报表元件类 rpt
TDDEClientConv,TDDEClientItem等所有的DDE元件类 dde
TMonthCalendar等所有的日历类 cal
TGroupBox等控件类 grp

如上所示，元件类型前缀是从分析描述元件的类型性质而来的。通常情况下，下面的规则描述如何定义一

个元件类型前缀：
◆从元件类型名中移去T前缀。例如TButton变成Button。
◆除了第一个元音，删去所有元音字母。例如，Button变成bttn，Edit变成edt。
◆压缩双字母。例如，bttn变成btn。
◆如发生冲突，则在某一元件前缀中加入一个元音。例如在TBatton元件的前缀中加入元音变为batn，以

区别TButton的前缀。
◆不过，上述规则首先得保证前缀名称必须符合习惯，做到见名知意，如:TDDEClientConv控件的前缀就

是一个例外。
注意：元件的前缀是为了表示出元件的类型，是按钮，还是标签等等，因此没有必要为每一个特别元件类

建立一个元件前缀，如: TMyButton的元件前缀仍为btn。

● 元件性质表示名
元件性质标识名是元件意图的描述。例如，一个用于关闭窗体的TButton元件实例可命名为btnClose。一

个编辑姓名的元件实例可命名为edName。

3.3.5窗体和对话框类型
□ 窗体类型的命名标准
窗体或对话框类型的名称应当表达出窗体的用途，如果是窗体要加“Tfrm”前缀，如果是对话框要加

“Tdlg”，后跟描述性名。例如，About窗体类型名称为：
TfrmAbout = class(TForm)
主窗体的类型名称为:
TfrmMain = class(TForm)
客户登录窗体的类型名称为:
TfrmCustomerEntry = class(TForm)
登录对话框的类型名称为：
TdlgLogin = class(TForm)

□ 窗体实例的命名标准
窗体实例的名称与相应的类型名称相同，但没有前缀T 。例如，前面提到的窗体类型与实例的名称为：
类型名 实例名
TfrmAbout frmAbout
TfrmMain frmMain
TfrmCustomerEntry frmCustomerEntry
TdlgLogin dlgLogin

□ 自动创建的窗体
除非特别原因,只有主窗体才自动生成。其他所有窗体必须从Project Options对话框的自动生成列表中删

除。更进一步信息,请参阅后面几节。

□ 模式窗体实例化函数
所有窗体单元都应当含有实例化函数，用于创建、设置、模式显示和释放窗体。这个函数将返回由窗体返

回的模式结果。传递给这个函数的参数遵循参数传递的规则。之所以要这样封装，是为了便于代码的重用

和维护。
窗体的变量应当从单元中移走，改在窗体实例化函数中作为局部变量定义(注意，要求从Project

Options对话框的自动生成列表中移走该窗体。请看前面的内容。
例如，下面的单元文件演示了GetUserData的实例化函数。
Unit UserDataFrm;
Interface
Uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
Type
TfrmUserData = class(TForm)
edtUserName: TEdit;
edtUserID: TEdit;
private
{ Private declarations }
public
{ Public declarations }
end;
function GetUserData(var aUserName: String;var aUserID: Integer): Word;
implementation
{$R *.DFM}
function GetUserData(var aUserName: String;var aUserID: Integer): Word;
var
frmUserData: TfrmUserData;
begin
frmUserData := TfrmUserData.Create(Application);
frmUserData.Caption:=’Getting User Data’ ;
Result : = frmUserData.ShowModal;
if Result=mrOK then
begin
aUserName := frmUserData.edtUserName.Text;
aUserID := StrToInt(frmUserData.edtUserID.Text);
end;
finally
frmUserData.Free;
end;
end;
End.

□ 窗体框架与复合窗体
如果一个窗体结构过于复杂，就必须将其分化成为一个主窗体框架以及嵌入到主窗体框架的若干子窗体框

架。如：TfrmMainFrame: TfrmInfoFrame,TfrmEditorFrame
使用窗体框架，主要是为了解决界面和代码复用问题，以及提高单元代码的内聚力（划分后，每一个

窗体框架为一个独立单元），从而提高软件工程质量。你必须提炼出界面关联代码（可复用的）和应用关

联代码（不能复用的）。

3.3.6数据模块类型
□ 数据模块的命名标准
数据模块类型名称应表达出它的用途，且要加前缀“Tdm”，后跟描述性名称。例如，Customer数据模块

的类型名称为：
TdmCustomer = class(TDataModule)
Orders 数据模块的类型名称为：
TdmOrder = class(TDataModule)

□ 数据模块的实例命名标准
数据模块实例的名称应当与相应的类型名称相同，但没有前缀T 。例如，前面的数据模块类型、实例名称

如下：
类型名称 实例名
TdmCustomer dmCustomer
TdmOrder dmOrder

3.4文件
建议在所有源文件、项目文件和单元文件使用结构化的文件头信息。一个文件头至少应包含以下信息：
{
Copyright @ Year by Authors
}
3.4.1项目文件
项目文件的名称应当具有描述意义。例如，“The Delphi 5 Developer’s Guide Bug Manager ”的项目

名称为DDGBugs.dpr，一个系统信息程序的名称为SysInfo.dpr。

3.4.2窗体文件
窗体文件的名称应当表达出窗体的用途，且具有Frm后缀。例如，About窗体的文件名叫AboutFrm.dfm，主

窗体的文件名叫MainFrm.dfm。

3.4.3数据模块文件
数据模块文件的名称应当表达出数据模块的作用，且具有DM后缀。例如，Customers数据模块的文件名叫

CustomersDM.dfm。

3.4.4远程数据模块文件
远程数据模块文件的名称应当表达出远程数据模块的用途。名称后要加RDM后缀。例如，Customers远程数

据模块的文件叫CustomersRDM.dfm。

3.4.5单元文件
□ 普通单元
● 单元名
单元的名称应当有描述性。例如，应用程序的主窗体单元叫MaimFrm.pas。
● Use子句
Interface部分的Uses子句应当只包含该部分需要的单元。不要包含可能由Delphi自动添加的单元名。

Implementation部分的Uses子句应当只包含该部分需要的单元，不要有多余的单元。
● Interface部分
Interface部分应当只包含需要被外部单元访问的类型、变量、过程与函数的声明。而且，这些声明应当

在Implementation部分之前。
● Implementation 部分
Implementation部分包括本单元私有的类型、变量、过程与函数的实现。
● Initialization 部分
不要在Initialization部分放置花费时间很多的代码。否则，将导致应用程序启动时显得很慢。
● Finalization 部分
确保释放所有在Initialization部分中分配的资源。

□ 窗体单元
窗体单元文件的名称与相应的窗体名称相同，只是要将前缀变成后缀。例如，About窗体的单元名称叫

AboutFrm.pas。主窗体的单元文件名称叫MainFrm.pas。

□ 数据模块单元
数据模块单元文件的名称与相应的数据模块名称相同。例如，数据模块单元的名称叫CustomersDM.pas。

□ 通用单元
通用单元的名称应当表达出它的用途，名称前要加“u”前缀。例如，一个实用调试工具单元的名称叫

uDebugUtilities.pas，包含全局变量的单元名称叫uCustomerGlobals.pas。
注意：一个项目中单元名称必须是唯一的。通用单元名不能重名。

□ 元件单元
● 命名
元件单元应放在单独的路径中，以表明它们是定义元件的单元。它们一般与项目不放在同一路径下。单元

文件名称应表达出其内容。
注意，有关元件命名标准的更多信息，请参阅“元件类型的命名标准”。元件单元只能含有一个主要元件

，这是指出现在元件选项板上的元件。其他辅助性的元件或对象也可以包含在同一单元中。

● 注册单元
元件的注册过程应当从元件单元中移走，放在一个单独的单元中。这个注册单元用于注册所有元件、属性

编辑器、元件编辑器、向导等。元件注册应当在设计期包中进行。因此，注册单元应当包含在设计期包而

不是运行期包中。建议注册单元这样命名：
xxxReg.pas
其中，xxx字符前缀，以标识元件包名称或公司、个人、其他实体。例如，注册单元命名为xxxReg.pas。

□ 包文件（。Dpk）命名规则
● 运行期包与设计期包
运行期包中应当只包含所需要的单元。那些属性编辑器和元件编辑器的单元应当放在设计期包中。注册单

元也应当放在设计期包中。

● 文件命名规则
包的命名遵循下列模式：
dcliiiDescvvCn.pkg —设计期包
iiiDescvvCn.pkg —运行期包
其中，iii代表一个2-3字符的前缀，用于标识公司、个人或其他需要标识的事情，也可不要；Desc表

示该控件包的简短描述；vv代表包的版本号，你可以根据需要取舍；前缀“dcl”表示设计期包，没有该

前缀表示运行期包；字母“Cn”表示编译器类型与编译器版本号，如：Delphi5=D5, Delphi4=D4,

CBuilder3=C3…。
注意包名称中的lib或std分别表示这是设计期包还是运行期包。例如：
dclrbStdCompsD5.pkg —Delphi 5的设计期包
rbStdCompsD5.pkg —Delphi 5的运行期包

4、Delphi代码自动格式化工具
尽管大多数的代码自动格式化工具能够帮你重排源程序格式，以及更新保留字和标示符的大小写

，但是这最好在使用版本控制前进行，如果你已经使用了版本控制，建议你不要轻易使用代码自动格式化

工具，哪怕多一个空格，版本控制工具也会认为该行已被修改，从而给程序管理带来不变。