做为一个老程序员， 我有资格说下面的话：
我生来命苦，从来只有修改别人程序写的程序的份，到过的几家公司都是这样，以前留下来项目都是赶进度匆忙做出来，没有经过认真详细的周密设计，程序员们也只是为应付交差。 只等我等后来维护的人的受苦， 改吧， 那程序简直无法看下去， 重写吧， 项目一个接一个你哪来那个时间与精力！我现在脾气都变得太连自己都不相信了， 真的是越来暴燥动不动就发火， 越来越不堪重负， 我怕长此下去， 我精神要垮了。
是否现在的程序员水平在下降？做为程序员的你是否应该认真审视一下你自己呢？以下文章非本人把所创， 大家认真看看吧， 我希望大家写出来的程序能够想VCL的源吗一样， 让人觉得是一份享受， 而不是深恶痛绝！
-------------------------------------------------------------
Delphi 4 程序员代码编写标准指南
版权所有 1998 Xavier Perched和 Steve Teiseira一、序言
二、通用源代码格式规则
2.1 缩格
2.2 页边空格
2.3 Begin...End 配对
三、Object Pascal
3.1 括号
3.2 保留字和关键字
3.3 过程和函数（例程）
3.3.1 命名/格式化
3.3.2 形式参数
3.3.2.1 格式化
3.3.2.2 命名
3.3.2.3 参数的排序
3.3.2.4 常量参数
3.3.2.5 名称的冲突
3.4 变量
3.4.1 变量的命名和格式
3.4.2 局部变量
3.4.3 全局变量的使用
3.5 类型
3.5.1 大写约定
3.5.1.1 浮点指针类型
3.5.1.2 枚举类型
3.5.1.3 变数和ole变数类型
3.5.2 结构类型
3.5.2.1 数组类型
3.5.2.2 记录类型
3.6 语句
3.6.1 if 语句
3.6.2 case 语句
3.6.2.1 一般性话题
3.6.2.2 格式
3.6.3 while 语句
3.6.4 for 语句
3.6.5 repeat 语句
3.6.6 with 语句
3.6.6.1 一般话题
3.6.6.2 格式
3.7 结构异常处理
3.7.1 一般话题
3.7.2 try...finally的使用
3.7.3 try...except的使用
3.7.4 try...except...else的使用
3.8 类类型
3.8.1 命名和格式
3.8.2 域
3.8.2.1 命名/格式
3.8.2.2 可视化
3.8.3 方法
3.8.3.1 命名/格式
3.8.3.2 使用静态的方法
3.8.3.3 使用虚拟/动态的方法
3.8.3.4 使用抽象的方法
3.8.3.5 属性存取方法
3.8.4 属性
3.8.4.1 命名/格式
3.8.4.2 使用存取的方法
四、文件
4.1 工程文件
4.1.1 命名
4.2 窗体文件
4.2.1 命名
4.3 数据模板文件
4.3.1 命名
4.4 远端数据模板文件
4.4.1 命名
4.5 Unit文件
4.5.1 通用Unit结构
4.5.1.1 unit的名字
4.5.1.2 uses子句
4.5.1.3 interface部分
4.5.1.4 implementation部分
4.5.1.5 initialization部分
4.5.1.6 finalization部分
4.5.2 窗体单元
4.5.2.1 命名
4.5.3 数据模板单元
4.5.3.1 命名
4.5.4 一般目的单元
4.5.4.1 命名
4.5.5 构件单元
4.5.5.1 命名
4.6 文件头
五、窗体和数据模板
5.1 窗体
5.1.1 窗体类型命名标准
5.1.2 窗体实例命名标准
5.1.3 自动创建窗体
5.1.4 模式窗体实例化函数
5.2 数据模板
5.2.1 数据模板命名标准
5.2.2 数据模板实例命名标准
六、包
6.1 使用运行包和设计包的比较
6.2 文件命名标准
七、构件
7.1 用户自定义构件
7.2 构件单元
7.3 使用注册单元
7.4 构件实例命名约定
7.5 构件的前缀
7.6 Standard页
7.7 Additional页
7.8 Win32页
7.9 System页
7.10 Internet页
7.11 Data Access页
7.12 Data Controls页
7.13 Decision Cube页
7.14 QReport页
7.15 Dialogs页
7.16 Win3.1页
7.17 Samples页
7.18 ActiveX页
7.19 Midas页一、序言本文档详述了在Delphi 4开发者指南下进行编程的代码编写标准。在通常情况下，本文档遵循“取消”式格式的指引方针，该方针由Borland国际通过一些例外来使用。在Delphi 4开发者指南中包含本文档的目的在于阐述一种方法，通过该方法，开发小组可以在他们所编写的代码中保持一贯的风格。这样做的目的是使在开发小组中的每一个程序员都可以明白其他程序员的代码。这有助于提高代码编写的可读性和使用的一贯性。本文档并不意味着包含了所有存在于代码中的标准。但是，它的内容已足够帮你起个好头。你可以自由的增加修改这些标准来满足你的需要。我们不赞成你偏离这些由Borland开发人员所使用的标准太远。我们推荐这么做是因为一旦有新的程序员加入到你的开发小组中，而他们最喜欢和最熟悉的是Borland的标准。象大多数代码标准文档，本文档也会根据需要进行改动。因此，你可以到www.xapware.com/ddg中找到最新的更新版本。本文档不包括用户接口标准。本文档是独立的但也是同样重要的。已经有足够的第三方书籍和Microsoft文档包括了另外一些指导方针，而我们决定并不复制这些信息，但我们会指引你到Microsoft Developers Network 和一些资源，在那儿可以找到你所需的信息。二、通用源代码格式规则2.1 缩格缩格是指在每一级有两个空格。不要在源代码中保留tab字符，这是因为tab字符会随着不同用户的不同设置和不同的资源管理工具（打印、文档、版本控制等）而代表不同的宽度。你可以通过关闭Environment选项对话框中Editor页上的“Use tab character”和“Optimal fill”检查框（通过Tools|Environment）来禁止保存tab字符。2.2 页边空格页边空格会被设置成80字符宽。通常，源码不会超出这个边界，但这个方针会有一些弹性。不管是否有可能，那些超出到另一行的语句会在一个逗号或其他操作符之后与前面的语句相连。当一个语句被打断相连时，它应比原来的那一行语句缩进两个字符。2.3 Begin...End 配对Begin 子句应写在独立的一行。例如，下面第一行是错误的写法而第二行是正确的。
for I := 0 to 10 do begin //错误，begin同for在同一行
for I := 0 to 10 do //正确，begin出现在独立的一行
begin这个规则的例外是当begin子句的出现是作为一个else子句的一部分－参考例子：
if some statement then
begin
...
end
else begin
someOtherStatement;
end;end 语句永远出现在独立的一行。
当begin语句不是一个else子句的一部分时，相应的end语句永远缩进到与begin部分相对应的位置。三、Object Pascal3.1 括号永远不要在括号与括号之间的字符中间留下空格。下面的例子示范了错误的与正确地使用括号中的空格：
CallProc( Aparameter ); //错误
CallProc(Aparameter); //正确永远不要在一个语句中使用不必要的括号。括号只应在源代码中需要的地方使用。以下的例子示范了错误和正确的使用：
if (I = 42) then //错误 － 多余的括号
if (I = 42) or (J = 42) then //正确 － 需要括号3.2 保留字和关键字Object Pascal 保留字和关键字永远是全部小写。3.3 过程和函数（例程）3.3.1 命名/格式化例程的名字永远应该以大写的字母开头并且中间错落分明以便于可读性。下面是一个不正确格式的过程名称：
procedure thisisapoorlyformattedroutinename;下面是一个合适的大小写例程名称的例子：
procedure ThisIsMuchMoreReadableRoutineName;例程的名称应该同它的内容相符。一个会导致某个行为的例程应以动词开头。例如：
procedure FormatHardDrive;一个用于设置输入参数的例程应以单词set作为前缀，例如：
procedure SetUserName;一个用来接收某个值的例程应以单词get作为前缀，例如：
procedure GetUserName : string;
我生来命苦，从来只有修改别人程序写的程序的份，到过的几家公司都是这样，以前留下来项目都是赶进度匆忙做出来，没有经过认真详细的周密设计，程序员们也只是为应付交差。 只等我等后来维护的人的受苦， 改吧， 那程序简直无法看下去， 重写吧， 项目一个接一个你哪来那个时间与精力！我现在脾气都变得太连自己都不相信了， 真的是越来暴燥动不动就发火， 越来越不堪重负， 我怕长此下去， 我精神要垮了。
是否现在的程序员水平在下降？做为程序员的你是否应该认真审视一下你自己呢？以下文章非本人把所创， 大家认真看看吧， 我希望大家写出来的程序能够想VCL的源吗一样， 让人觉得是一份享受， 而不是深恶痛绝！
-------------------------------------------------------------
Delphi 4 程序员代码编写标准指南
版权所有 1998 Xavier Perched和 Steve Teiseira一、序言
二、通用源代码格式规则
2.1 缩格
2.2 页边空格
2.3 Begin...End 配对
三、Object Pascal
3.1 括号
3.2 保留字和关键字
3.3 过程和函数（例程）
3.3.1 命名/格式化
3.3.2 形式参数
3.3.2.1 格式化
3.3.2.2 命名
3.3.2.3 参数的排序
3.3.2.4 常量参数
3.3.2.5 名称的冲突
3.4 变量
3.4.1 变量的命名和格式
3.4.2 局部变量
3.4.3 全局变量的使用
3.5 类型
3.5.1 大写约定
3.5.1.1 浮点指针类型
3.5.1.2 枚举类型
3.5.1.3 变数和ole变数类型
3.5.2 结构类型
3.5.2.1 数组类型
3.5.2.2 记录类型
3.6 语句
3.6.1 if 语句
3.6.2 case 语句
3.6.2.1 一般性话题
3.6.2.2 格式
3.6.3 while 语句
3.6.4 for 语句
3.6.5 repeat 语句
3.6.6 with 语句
3.6.6.1 一般话题
3.6.6.2 格式
3.7 结构异常处理
3.7.1 一般话题
3.7.2 try...finally的使用
3.7.3 try...except的使用
3.7.4 try...except...else的使用
3.8 类类型
3.8.1 命名和格式
3.8.2 域
3.8.2.1 命名/格式
3.8.2.2 可视化
3.8.3 方法
3.8.3.1 命名/格式
3.8.3.2 使用静态的方法
3.8.3.3 使用虚拟/动态的方法
3.8.3.4 使用抽象的方法
3.8.3.5 属性存取方法
3.8.4 属性
3.8.4.1 命名/格式
3.8.4.2 使用存取的方法
四、文件
4.1 工程文件
4.1.1 命名
4.2 窗体文件
4.2.1 命名
4.3 数据模板文件
4.3.1 命名
4.4 远端数据模板文件
4.4.1 命名
4.5 Unit文件
4.5.1 通用Unit结构
4.5.1.1 unit的名字
4.5.1.2 uses子句
4.5.1.3 interface部分
4.5.1.4 implementation部分
4.5.1.5 initialization部分
4.5.1.6 finalization部分
4.5.2 窗体单元
4.5.2.1 命名
4.5.3 数据模板单元
4.5.3.1 命名
4.5.4 一般目的单元
4.5.4.1 命名
4.5.5 构件单元
4.5.5.1 命名
4.6 文件头
五、窗体和数据模板
5.1 窗体
5.1.1 窗体类型命名标准
5.1.2 窗体实例命名标准
5.1.3 自动创建窗体
5.1.4 模式窗体实例化函数
5.2 数据模板
5.2.1 数据模板命名标准
5.2.2 数据模板实例命名标准
六、包
6.1 使用运行包和设计包的比较
6.2 文件命名标准
七、构件
7.1 用户自定义构件
7.2 构件单元
7.3 使用注册单元
7.4 构件实例命名约定
7.5 构件的前缀
7.6 Standard页
7.7 Additional页
7.8 Win32页
7.9 System页
7.10 Internet页
7.11 Data Access页
7.12 Data Controls页
7.13 Decision Cube页
7.14 QReport页
7.15 Dialogs页
7.16 Win3.1页
7.17 Samples页
7.18 ActiveX页
7.19 Midas页一、序言本文档详述了在Delphi 4开发者指南下进行编程的代码编写标准。在通常情况下，本文档遵循“取消”式格式的指引方针，该方针由Borland国际通过一些例外来使用。在Delphi 4开发者指南中包含本文档的目的在于阐述一种方法，通过该方法，开发小组可以在他们所编写的代码中保持一贯的风格。这样做的目的是使在开发小组中的每一个程序员都可以明白其他程序员的代码。这有助于提高代码编写的可读性和使用的一贯性。本文档并不意味着包含了所有存在于代码中的标准。但是，它的内容已足够帮你起个好头。你可以自由的增加修改这些标准来满足你的需要。我们不赞成你偏离这些由Borland开发人员所使用的标准太远。我们推荐这么做是因为一旦有新的程序员加入到你的开发小组中，而他们最喜欢和最熟悉的是Borland的标准。象大多数代码标准文档，本文档也会根据需要进行改动。因此，你可以到www.xapware.com/ddg中找到最新的更新版本。本文档不包括用户接口标准。本文档是独立的但也是同样重要的。已经有足够的第三方书籍和Microsoft文档包括了另外一些指导方针，而我们决定并不复制这些信息，但我们会指引你到Microsoft Developers Network 和一些资源，在那儿可以找到你所需的信息。二、通用源代码格式规则2.1 缩格缩格是指在每一级有两个空格。不要在源代码中保留tab字符，这是因为tab字符会随着不同用户的不同设置和不同的资源管理工具（打印、文档、版本控制等）而代表不同的宽度。你可以通过关闭Environment选项对话框中Editor页上的“Use tab character”和“Optimal fill”检查框（通过Tools|Environment）来禁止保存tab字符。2.2 页边空格页边空格会被设置成80字符宽。通常，源码不会超出这个边界，但这个方针会有一些弹性。不管是否有可能，那些超出到另一行的语句会在一个逗号或其他操作符之后与前面的语句相连。当一个语句被打断相连时，它应比原来的那一行语句缩进两个字符。2.3 Begin...End 配对Begin 子句应写在独立的一行。例如，下面第一行是错误的写法而第二行是正确的。
for I := 0 to 10 do begin //错误，begin同for在同一行
for I := 0 to 10 do //正确，begin出现在独立的一行
begin这个规则的例外是当begin子句的出现是作为一个else子句的一部分－参考例子：
if some statement then
begin
...
end
else begin
someOtherStatement;
end;end 语句永远出现在独立的一行。
当begin语句不是一个else子句的一部分时，相应的end语句永远缩进到与begin部分相对应的位置。三、Object Pascal3.1 括号永远不要在括号与括号之间的字符中间留下空格。下面的例子示范了错误的与正确地使用括号中的空格：
CallProc( Aparameter ); //错误
CallProc(Aparameter); //正确永远不要在一个语句中使用不必要的括号。括号只应在源代码中需要的地方使用。以下的例子示范了错误和正确的使用：
if (I = 42) then //错误 － 多余的括号
if (I = 42) or (J = 42) then //正确 － 需要括号3.2 保留字和关键字Object Pascal 保留字和关键字永远是全部小写。3.3 过程和函数（例程）3.3.1 命名/格式化例程的名字永远应该以大写的字母开头并且中间错落分明以便于可读性。下面是一个不正确格式的过程名称：
procedure thisisapoorlyformattedroutinename;下面是一个合适的大小写例程名称的例子：
procedure ThisIsMuchMoreReadableRoutineName;例程的名称应该同它的内容相符。一个会导致某个行为的例程应以动词开头。例如：
procedure FormatHardDrive;一个用于设置输入参数的例程应以单词set作为前缀，例如：
procedure SetUserName;一个用来接收某个值的例程应以单词get作为前缀，例如：
procedure GetUserName : string;
procedure Foo(Param1, Param2, Param3 : Integer; Param4 : string);3.3.2.2 命名所有形参的名字应是十分符合它们所代表的意义，特别是应该以传送到例程中的标志符的名称为基础。一个好的参数名称应以字符A为前缀 － 例如：
procedure SomeProc(AuserName : string; AuserAge : integer);“A”前缀按约定表示该参数的名称是与类类型中的一个属性或域的名称相对应的。3.3.2.3 参数的排序下面的形参的顺序重点说明了注册者调用约定调用的好处。－ 最常用的参数应放在第一位，其它的参数应按从左到右的顺序排列。
－ 输入参数列表应放在输出参数列表的左边。
－ 将通用的参数放在特殊参数的左边，例如：
procedure SomeProc(Aplanet, AContinent, Acountry, Astate, Acity)
－ 排序有可能有些例外，比如事件的处理。类型为TObject的Sender参数经常放在第一位。3.3.2.4 常量参数当一个参数为记录型、数组类型、ShortString、或接口类型并且在例程中不被改变时，这些参数应做上常量标记。这样做会让编译器更加有效率的产生有关这些不改变的参数的代码。而例程中另外一些非变参数也可常量来传送。尽管这样做没有产生任何效果和提高效率，这将会给调用例程的使用者提供更多的信息。3.3.2.5 名称的冲突当使用拥有两个名称相同的例程的两个单元时，如果你调用该例程时，在uses子句中排在后面的单元中的例程将会被调用。为了解决这种“在uses子句上的模糊”冲突，要在调用该例程时写上相关的单元的前缀，例如：
sysUtile.FindClose(SR);
或
windows.FindClose(Handle);3.4 变量3.4.1 变量的命名和格式变量的命名应以使用它们的目的相符循环控制变量应采用一个单独的字符作为名字，比如 I，J，或K，也可以采用更加有意义的名字，比如 UserIndex。逻辑变量的名字应能充分表达准确的真或假的意思。3.4.2 局部变量一个过程中的局部变量应遵循所有其它变量的使用和命名约定。临时变量的取名应合理。如果必须的话，在一进入例程就应初始化局部变量。局部的AnsiString变量会自动初始化为一个空的字符串。
局部接口和派分接口类型变量将会自动初始化为nil，并且局部变数和ole变数类型变量会自动初始化为Unassigned3.4.3 全局变量的使用使用全局变量是不推荐的。但是，在某些时候还是必须使用，而且它们也只应在必须使用的时候才使用。在这种时候，你应努力只在一段上下文范围内使用全局变量。例如，一个全局变量只应在一个单元的implemntation部分内是全局的。如果打算在多个单元类使用全局数据，你应将它们移到一个公共的单元中然后被其它所有单元使用。全局变量可以在var子句中直接初始化为一个值。记住，所有的全局数据会自动初始化为0,因此不要将全局变量初始化为一个“空”值比如 0、nil、''、Unassigned、等等。这样做的一个理由是因为零－初始化的全局数据在exe文件中不会占据任何空间。零－初始化数据被存储在一个虚拟的数据段，它在应用程序启动后被分配在一段内存中。非零－初始化的全局数据在硬盘的exe文件占用空间。3.5 类型3.5.1 大写约定如果类型的名字是保留字，那么它应全部小写。Win32 API类型通常全部大写，并且你必须遵循在Windows.pas或其他API单元中的详细类型名称的约定。对于其他变量名字，地一个字母应为大写，而其他字母应错落有致。下面是一些例子：
var
MyString : string; //保留字
WindowHandle : HWND; //Win32 API 类型
I : Integer; //在System单元中引进的类型标识符3.5.1.1 浮点指针类型不推荐使用Real类型，因为它的存在只是为了向前兼容早期的Pascal代码。在通常情况下用Double来实现浮点指针的需要。并且，Double对处理器和总线而言是做了最优化处理的，它也是IEEE中定义的标准数据格式。只有当需要的范围超出Double所定义的范围时才使用Extended。Extended是intel定义的类型且在Java中不支持。只有当浮点指针变量的实际字节大小有其意义时才使用Single。（比如当使用另一种语言的DLLs时）。3.5.1.2 枚举类型枚举类型的名字需符合使用该类型的目的。该类型的名字需以字符T为前缀，以表明这是一个类型。枚举类型中的标识符列表必须包含两个或三个字符的前缀来对应于该枚举类型的名字 － 例如：
TsongType = (stRock, stClassical, stCountry, stAlternative, stHeavyMetal, stRB);
一个枚举类型的实例的名字应与不要前缀的枚举类型（SongType）相同，除非有更好的原因来赋予该变量更特殊的名字，比如：FavoriteSongType1,FavoriteSongType2 等等。3.5.1.3 变数和ole变数类型通常不建议使用变数和Ole变数类型。但在只有运行时刻才能知道数据类型的程序中必须使用该类型，这种情形多出现在COM和数据库开发中。Ole变数使用在以COM为基础的编程中例如自动化和ActiveX控制，而变数使用在非COM的编程中，这是因为变数可以十分有效地存储本地Delphi字符串（同一个字符串变量一样），但Ole变数会将所有的字符串转换为Ole字符串（WideChar 字符串）并且并不实例运算 － 它们永远拷贝。3.5.2 结构类型3.5.2.1 数组类型数组类型的名字需符合它们使用的目的。该类型的名字必须加以前缀T。如果须声明该数组类型的指针，那么该指针需加以前缀P而且应立即声明在该数组声明的前面。例如：
type
PCycleArray = ^TCycleArray;
TCycleArray = array[1...100] of integer;
在实际应用中，数组的变量实例的名称应是其类型的名字去掉前缀T。3.5.2.2 记录类型记录类型的名字应符合使用它们的目的。其类型的声明应加以前缀T。如果要声明该记录类型的指针，就应加以前缀P并且应紧靠在类型声明的前面声明。例如：
type
PEmployee = ^TEmployee;
TEmployee = record
EmployeeName : string;
EmployeeRate : Double;
end;
if 条件1 and 条件2 and 条件3 then3.6.2 case 语句3.6.2.1 一般性话题在一个case语句中的各个独立的单元应以数字或字母顺序排列。每一个case单元的动作行为应保持简单而不应该超过四到五行代码。如果所要执行的动作过于复杂应采用独立的过程或函数。Case语句中的else子句只有当需要缺省行为或处理错误时才使用。3.6.2.2 格式case语句应遵循其它结构的缩格和命名约定。3.6.3 while 语句在一个while语句中不建议使用exit过程来跳出循环，尽量仅使用循环条件来跳出循环。在一个while循环中所用的初始化代码应紧靠在进入while循环前面出现而不要被其它不相关的语句隔开。任何结束后的处理应在循环之后立即进行。3.6.4 for 语句for语句只有当循环次数已知的情况下才能取代while语句使用。3.6.5 repeat 语句repeat语句的使用同while语句一样，并且遵循同样的通用方针。3.6.6 with 语句3.6.6.1 一般话题with语句应节省使用，并且带有大量的警告。避免过度使用with语句并且在with语句中小心使用多个对象、记录等等。例如：
with Record1, Record2 do
这些事情会使程序员感到困惑并难以发现问题所在。3.6.6.2 格式with 语句遵循本文档所说明的命名约定和缩格的格式规则。3.7 结构异常处理3.7.1 一般话题异常的处理大量地使用在错误纠正和资源保护方面。这就是说一旦资源被分配，一个try...finally必需加以使用来保证该资源被正确的释放。这种异常的保护也是指在一个单元的initializition/finalization或一个对象的constructor/destructor中进行资源的分配和释放。3.7.2 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;3.7.3 try...except的使用只有当在异常被触发而你想执行一些任务时才使用try...except。通常，你没有必要为了只是简单地在屏幕上显示一个错误信息而使用try...except语句，因为这会被Application对象自动执行。如果你想在except子句中执行完一些任务之后调用缺省的异常处理，使用raise来重新触发异常到下一个句柄。3.7.4 try...except...else的使用try...except中的else子句不建议使用，因为它会打断所有的异常包括那些你没有准备的异常。3.8 类类型3.8.1 命名和格式类类型的名称应符合使用它们的目的。类型名字应加以前缀T以表明这是一个类型的定义 － 例如：
type
Tcustomer = class(TObject)
类型的实例通常是没有前缀T的类型的名字 － 例如：
var
Customer :Tcustomer;
注意：查阅“构件类型的命名标准”来获得更多有关构件命名的信息。3.8.2 域3.8.2.1 命名/格式类的域名遵循与变量标识符同样的约定除了它们应以F为前缀，来表明这是一个域的名称。3.8.2.2 可视化所有的域都必需是私有的。想在类的范围之外存取域得通过属性来使用。3.8.3 方法3.8.3.1 命名/格式方法的命名应遵循本文档中有关过程和函数的约定叙述。3.8.3.2 使用静态的方法如果使用一个静态的方法，那么该方法就不能被该类的后代类所继承。3.8.3.3 使用虚拟/动态的方法如果你打算该类的方法能被后代的类所继承就得使用虚拟的方法。只有在该方法有多个继承时（直接的或间接的）才使用动态的方法。例如，一个类类型包含一个可继承的方法，而100个后代类要继承这种方法，那么这个方法就会动态地产生为100个后代类使用的内存。3.8.3.4 使用抽象的方法如果在一个类中使用抽象的方法，该类就不能被创建。只有在那些永远不会被创建的类中使用抽象的方法。3.8.3.5 属性存取方法所有存取类的方法都只能出现在类的private或protected部分。属性存取方法的命名应遵循过程和函数的约定规则。读取存取方法（方法读取器）必需以单词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;3.8.4 属性3.8.4.1 命名/格式属性如果是表示为一个私有域的存取器的话，那么它的名字应是它们所操作的域的名字除去解释符F。属性的名字应是名词，不是动词。属性表示的是数据，而方法表示的是行为。数组类型的名称应为复数。一般情况下属性的名称应为单数。3.8.4.2 使用存取的方法尽管没有要求，但还是建议尽量少地为一个表示私有域的属性而使用写入存取方法。
得比较缓慢。4.5.1.6 finalization部分在这里要保证释放你在Initialization部分所分配的任何资源。4.5.2 窗体单元4.5.2.1 命名一个窗体的单元文件应拥有与它所对应的窗体文件同样的名称。例如，“关于”窗体的单元名称应为 AboutFrm.pas，而主窗体的单元名称应为MainFrm.pas。4.5.3 数据模板单元4.5.3.1 命名一个数据模板的单元文件应拥有与它所对应的数据模板文件同样的名称。例如，一个自定义数据模板单元的名称应为CustomersDM.pas。4.5.4 一般目的单元4.5.4.1 命名一般目的单元的取名应符合使用该单元的目的。例如，一个实用程序单元取名为BugUtilities.pas。一个包含全局变量的单元取名为CustomerGlobals.pas。注意，该单元的名字不能与它的工程中所使用的所有包中的单元的名字相同。不赞成使用一般的或通用的单元名字。4.5.5 构件单元4.5.5.1 命名构件单元应放在独立的目录，以将它们同定义构件组或构件集合的单元区分开来。它们要永远同工程在不同的目录。单元名字应同它们的内容相符。注意：查阅“用户定义的构件”部分来获得更多有关构件命名标准的信息。4.6 文件头建议在所有源文件、工程文件、单元等等中使用信息化文件头。一个良好的文件头应包含以下信息：
｛
版权... 著作的年、月、日...
}
回复不能超过三次， 文章不允许太长，
抱歉了各位：
续
-------------------------------------------------
五、窗体和数据模板5.1 窗体5.1.1 窗体类型命名标准窗体类型的取名应能表达使用该窗体的目的。类型定义应加以前缀T。前缀后面跟随着描述性的名字。最后，应加以Form后缀来描述名字。例如，一个“关于”的窗体的类型的名字应为：
TAboutFrom = class(TForm);
主窗体的定义为：
TMainForm = class(TForm);
一个用户接入窗体的名字应象：
TCustomerEntryForm = class(TForm);5.1.2 窗体实例命名标准窗体实例应是没有带前缀T的相应类的名字。例如，对应于前面窗体类型而言，其实例的名字应为： 类型名称 实例名称
TAboutForm AboutForm
TMainForm MainForm
TCustomerEntryForm CustomerEntryForm5.1.3 自动创建窗体只有主窗体可以是自动创建的除非有其它更好的理由不这样做。所有其它的窗体必需从工程选项对话框中的自动创建列表中移走。查阅以下部分来获得更多的信息。5.1.4 模式窗体实例化函数所有的窗体单元都应包含一个窗体实例化函数，该函数用来创建、设置、模式地显示窗体，并释放窗体。该函数应返回窗体的模式结果。该函数要传递的参数应遵循本文档指定的“参数传递”标准。通过这种方式封装的函数性有助于代码的再利用和维护。该窗体的变量要从单元中移走，并再窗体实例的函数中进行本地式地定义。注意，这就意味着该窗体必需从工程/选项对话框中的自动创建列表中剔除。参考本文档后面的“自动创建窗体”。例如，下面的单元展示了再GetUserData窗体中的一个函数。
unit UserDataFrm;
interface
uses
windows, Messages, SysUtils, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
type
TUserDataForm = 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
UserDataForm : TuserDataForm;
begin
UserDataForm := TuserDataForm.Create(Application);
try
UserDataForm.Caption := 'Getting User Data';
Result := UserDataForm.ShowModal;
if (Result = mrOK) then
begin
aUserName := UserDataForm.edtUserName.Text;
aUserID := StrToInt(UserDataForm.edtUserID.Text);
end;
finally
UserDataForm.Free;
end;
end;
end.5.2 数据模板5.2.1 数据模板命名标准数据模板的取名要符合使用该数据模板的目的。类型的定义应加以前缀T，后面紧接着描述性的名字，最后要加以后缀单词“DataModule”。例如，一个自定义的数据模板有时候应该象：
TCustomerDataModule = class(TDataModule)
一个命令式的数据模板的名字应象：
TOrdersDataModule = class(TDataModule)5.2.2 数据模板实例命名标准数据模板实例的名称应是对应不带前缀T的类型的名称。例如，对于前面的窗体类型而言，其实例的名称应为：
类型名称 实例名称
TCustomerDataModule CustomerDataModule
TOrdersDataModule OrdersDataModule六、包6.1 使用运行包和设计包的比较运行时刻的包应只包含其它构件包所要求的单元或构件。另外，包含属性/构件编辑器和其它只为设计的代码应放入到设计时刻包中。注册单元应放在设计包中。6.2 文件命名标准包的名称应依照下面的例子：
“iiilibvv.pkg” － 设计时刻包
“iiistdvv.pkg” － 运行时刻包
字符“iii”表示一个3字符标识前缀。这个前缀用来表明公司、个人或其它有标识意义的实体。字符“vv”表示为该包想要对应Delphi某个版本的包的版本号。注意，包的名字中包含“lib”或“std”的意思是表明这是一个设计时刻包还是一个运行时刻包。如果既是设计时刻包又是运行时刻包，该文件的命名是同上面一样的，例如，为Delphi 4开发者指南做的包的名称应为：DdgLib40.pkg - 设计时刻包
DdgStd40.pkg - 运行时刻包七、构件7.1 用户自定义构件在标准构件中命名出来的构件的名称同在“类类型”部分定义中的一样定义成一个类类型，不同的是它们有一个3字符的指示前缀，这个前缀可以表示公司、个人或其它实体。例如，一个为Delphi 4开发者指南编写的时钟构件的名称定义为：
TddgClock = class(TComponent)
注意，那三个前缀字符是小写的。7.2 构件单元构件单元应只包含一个主要的构件，一个主要的构件是指出现在构件栏中的构件。主要构件的辅助构件/对象应放入到同一个单元中。7.3 使用注册单元构件的注册过程应从构件本身的单元中剔除，并放入到一个独立的单元中。这个注册单元可以用来注册任何构件、属性编辑器、构件编辑器、专家器等。构件的注册只应在设计时刻包中进行，注册单元应包含在设计时刻包中而不应放在运行时刻包中。推荐使用的注册单元的名称是：
XxxReg.pas
上面的3个前缀字符“Xxx”用来表示一个公司、个人或任何其它的实体。例如，在Delphi 4 开发者指南中的注册单元的名称应为 DdgReg.pas。7.4 构件实例命名约定所有的构件都应取个描述性的名称。由Delphi创建的缺省名的构件不会被遗弃。在设计构件类型时应设计一个小写的前缀。使用前缀而不使用后缀的原因是在搜寻时，在对象检查器和代码探索器中搜寻构件的名字比搜寻构件的类型更容易实现。
晕，差点看错，哈哈哈哈哈
一、前言：
为了便于源程序的交流，减少合作开发中的障碍， Mental Studio 特制定了本规范。本规范的描述主要以 Borland C++ Builder 语言为例，对 Borland Delphi 的特别说明见附录一。二、规范：以下对本规范作详细说明。
1．源程序文件组织：每个程序文件单元通常都应由 .h 文件和 .cpp 文件组成，并将单元的公共声明部分放在 .h 文件中。划分单元主要是以类为依据，原则上每个较大的类都应为一个单独的单元，但在类较小且多个小类关系密切等情况下也可几个类共一个单元（建议仅对已经详细测试的较为通用的类采用）。
2．源程序文件结构：每个程序文件应由标题、内容和附加说明三部分组成。
（1）标题：文件最前面的注释说明，其内容主要包括：程序名，作者，版权信息，简要说明等，必要时应有更详尽的说明（将以此部分以空行隔开单独注释）。
（2）内容：为文件源代码部分基本上按预处理语句、类型定义、变量定义、函数原型、函数实现（仅对 .cpp 文件）的顺序。 main 、 winmain ，控件注册等函数应放在内容部分的最后，类的定义按 private 、 protected 、 pubilic 、 __pubished 的顺序，并尽量保持每一部分只有一个，各部分中按数据、函数、属性、事件的顺序。
（3）附加说明：文件末尾的补充说明，如参考资料等，若内容不多也可放在标题部分的最后。
3．编辑风格：
（1）缩进：缩进以 Tab 为单位，一个 Tab 为四个空格大小。预处理语句、全局数据、函数原型、标题、附加说明、函数说明、标号等均顶格书写。语句块的“{”“}”配对对齐，并与其前一行对齐，语句块类的语句缩进建议每个“{”“}”单独占一行。
（2）空格：数据和函数在其类型，修饰（如 __fastcall 等）名称之间适当空格并据情况对齐。关键字原则上空一格，如： if ( ... ) 等，运算符的空格规定如下：“::”、“->”、“[”、“]”、“++”、“--”、“~”、“!”、“+”、“-”（指正负号），“&”（取址或引用）、“*”（指使用指针时）等几个运算符两边不空格（其中单目运算符系指与操作数相连的一边），其它运算符（包括大多数二目运算符和三目运算符“?:”两边均空一格，“(”、“)”运算符在其内侧空一格，在作函数定义时还可据情况多空或不空格来对齐，但在函数实现时可以不用。“,”运算符只在其后空一格，需对齐时也可不空或多空格，“sizeof”运算符建议也在其后空一格，不论是否有括号，对语句行后加的注释应用适当空格与语句隔开并尽可能对齐。
（3）对齐：原则上关系密切的行应对齐，对齐包括类型、修饰、名称、参数等各部分对齐。另每一行的长度不应超过屏幕太多，必要时适当换行，换行时尽可能在“,”处或运算符处，换行后最好以运算符打头，并且以下各行均以该语句首行缩进，但该语句仍以首行的缩进为准，即如其下一行为“{”应与首行对齐。
（4）空行：程序文件结构各部分之间空两行，若不必要也可只空一行，各函数实现之间一般空两行，由于BCB会自动产生一行“//------”做分隔，另因每个函数还要有函数说明注释，故通常只需空一行或不空，但对于没有函数说明的情况至少应再空一行。对自己写的函数，建议也加上“//------”做分隔。函数内部数据与代码之间应空至少一行，代码中适当处应以空行空开，建议在代码中出现变量声明时，在其前空一行。类中四个“p”之间至少空一行，在其中的数据与函数之间也应空行。
（5）注释：对注释有以下三点要求：
A.必须是有意义；
B.必须正确的描述了程序；
C.必须是最新的。
注释必不可少，但也不应过多，以下是四种必要的注释：
A.标题、附加说明；
B.函数说明：对几乎每个函数都应有适当的说明，通常加在函数实现之前，在没有函数实现部分的情况下则加在函数原型前，其内容主要是函数的功能、目的、算法等说明，参数说明、返回值说明等，必要时还要有一些如特别的软硬件要求等说明；
C.在代码不明晰或不可移植处应有少量说明；
D.及少量的其它注释。
注释有块注释和行注释两种，分别是指：“/**/”和“//”建议对A用块注释，D用行注释，B、C则视情况而定，但应统一，至少在一个单元中B类注释形式应统一。
4． 命名规范：坚持采用匈牙利变量命名惯例，类型名称按Borland惯例用“T”做前缀，参数的命名统一以小写“a”前缀，所有标识符一律用英文或英文缩写，杜绝采用拼音，标识符中每个单词首字母大写，缩写词汇一般全部大写，只在必要时加“_”间隔词汇，用 #define 定义的宏一般全部大写，其它具体细节待定。三、补充说明：本规范历史： 1996年 8月 1.0口头版
1997年11月20日 2.0版
1999年 7月 1日 3.0版
2000年12月16日 3.01修订版 猛禽 Dec.16-2k
由 阿土 录入 附录一
对 Borland Delphi 的补充说明：
虽然 Delphi 是大小写无关的，但建议仍按大小写有关的方式编程，保持标识符的大小写一致，对于关键字的大小写可采用全部小写，全部大写或首字母大写等方式，但必须保持统一。 Delphi 支持多种多种块注释方式，建议采用“(* ... *)”的方式，以和编译指令“{$ ... }”及和 C/C++ 有所区别。附录二
匈牙利命名法(Hungarian-Notation)：
据说这种命名法是一位叫 Charles Simonyi 的匈牙利程序员发明的，后来他在微软呆了几年，于是这种命名法就通过微软的各种产品和文档资料向世界传播开了。现在，大部分程序员不管自己使用什么软件进行开发，或多或少都使用了这种命名法。这种命名法的出发点是把量名变按：属性+类型+对象 描述的顺序组合起来，以使程序员操作变量时对变量的类型和其它属性有直观的了解，下面是HN变量命名规范，其中也有一些是我个人的偏向：属性部分
全局变量 g_
常量 c_
c++类成员变量 m_
静态变量 s_
类型部分
指针 p
函数 fn
无效 v
句柄 h
长整型 l
布尔 b
浮点型（有时也指文件） f
双字 dw
字符串 sz
短整型 n
双精度浮点 d
计数 c（通常用cnt）
字符 ch（通常用c）
整型 i（通常用n）
字节 by
字 w
实型 r
无符号 u
最大 Max
最小 Min
初始化 Init
临时变量 T（或Temp）
源对象 Src
目的对象 Dest
这里顺便写几个例子：
hwnd ： h 是类型描述，表示句柄， wnd 是变量对象描述，表示窗口，所以 hwnd 表示窗口句柄；
pfnEatApple ： pfn 是类型描述，表示指向函数的指针， EatApple 是变量对象描述，所以它表示指向 EatApple 函数的函数指针变量。
g_cch ： g_ 是属性描述，表示全局变量，c 和 ch 分别是计数类型和字符类型，一起表示变量类型，这里忽略了对象描述，所以它表示一个对字符进行计数的全局变量。
上面就是HN命名法的一般规则。（摘自《电脑高手》2000年第八期，有删节。）
由 阿土 提供附录三
其它的编程风格规范（供参考）：
在软件编程过程中，如果每个程序员都按自己的习惯和风格编写程序，这种因人而异的程序风格势必降低程序的可读性，对软件的测试、交流、重用以及软件的维护产生极为不利的影响。为了解决这个问题，最终提高开发效率，必须执行本规范。
本规范在编程基本风格、可读性、结构化、正确性与容错性、可重用性等方面提出了要求，它是程序员编程素质的综合体现。
程序员的编程水平＝编程规范＋编程效率。1.基本要求
1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3尽量使用标准库函数和公共函数。
1.4不要随意定义全局变量，尽量使用局部变量。
1.5使用括号以避免二义性。2.可读性要求
2.1可读性第一，效率第二。
2.2保持注释与代码完全一致。
2.3每个源程序文件，都有文件头说明，说明规格见规范。
2.4每个函数，都有函数头说明，说明规格见规范。
2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7常量定义（DEFINE）有相应说明。
2.8处理过程的每个阶段都有相关注释说明。
2.9在典型算法前都有注释。
2.10利用缩进来显示程序的逻辑结构，缩进量一致并以 Tab 键为单位，定义Tab为 6个字节。
2.11循环、分支层次不要超过五层。
2.12注释可以与语句在同一行，也可以在上行。
2.13空行和空白字符也是一种特殊注释。
2.14一目了然的语句不加注释。
2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16注释行数（不包括程序头和函数头说明部分）应占总行数的 1/5 到 1/3 。3.结构化要求
3.1禁止出现两条等价的支路。
3.2禁止GOTO语句。
3.3用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4用 CASE 实现多路分支。
3.5避免从循环引出多个出口。
3.6函数只有一个出口。
3.7不使用条件赋值语句。
3.8避免不必要的分支。
3.9不要轻易用条件分支去替换逻辑表达式。4.正确性与容错性要求
4.1程序首先是正确，其次是优美
4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4所有变量在调用前必须被初始化。
4.5对所有的用户输入，必须进行合法性检查。
4.6不要比较浮点数的相等， 如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。
4.8单元测试也是编程的一部分，提交联调测试的程序必须通过单元测试。5.可重用性要求
5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3公共控件或类应建立使用模板。由 阿土 提供猛禽 Mar.26-01
特别感谢：网友 阿土 的录入！以及提供附录二/三的内容。
这个不是理由，好习惯是慢慢养成的，关键是要有这样的意识
thx
记得刚进公司的时候,公司的技术总监发给俺的第一份文档就是<<Delphi源程序书写标准>>
up! up! up!
我想我用过的语言也不会比你少。
语言规范与清晰是非常重要， 能不能合理有效地规划好你的程序结构， 就可以看出这个程序员的功底有多深， 一个写好的程序是对象的集合而不是代码的堆积， 是界面与业务逻辑的分离， 而不是一锅粥。
不管哪种语言都应该有规范，除非你从来都只是单打独斗。
===========================================================
一个用于设置输入参数的例程应以单词set作为前缀，例如：
procedure SetUserName;一个用来接收某个值的例程应以单词get作为前缀，例如：
procedure GetUserName : string;
===========================================================
有何意义？对吗？