Delphi编程建议遵守的规范1---缩进、各种语句的用法

时间:2022-11-07 17:20:32

在编程时候,尤其是在一个大的团队里面,遵守统一的编程规范是极其重要的。为所有的开发人员制定一个源代码书写标准,以及程序和文件的命名标准,使他们在编程时有一致的格式,这样,每个编程人员编写的代码能够被其他人理解,减少程序维护和移交的成本。

这里先只介绍关于Delphi语言的编程规范,暂时跳过文件、项目命名……

1.1.关于缩进

缩进能够更清晰的展示源码的逻辑结构,采用两个空格字符,不能使用制表符(即Tab字符)。这是因为,制表符的宽度随着不同源码编缉工具及不同的设置,展示出来的效果不一样,如果空格和tab键混用的情况,很可能展现出来的是混乱的结构

1.2.begin...end语句

begin语句应该单独占一行,例如

错误的用法

for i:=0 to 10 do begin

     正确的用法

for i:=0 to 10 do
begin

    本规则有一个特例,当begin为else语句的一部分时,例如

if somestatement then
begin
...
end;
else someotherstatement begin
...
end;

   注意:end语句总是单独一行,当begin不为else语句的一部分时,相应的end语句与begin语句的缩进量相同

1.3.大小写规则

虽然Delphi中不区分大小写,但是采用统一的大小写规则也是极其有益的,能让大家在看代码时不至于不知所措

类型标识符是保留字,应当全部小写。Win32 API类型常常全部大写,并且遵循如Windows.pas或者其他API单元中关于特定类型名的规则。对于凄然变量名,第一个字母应该大写,其他字母则大小写交错,例子

var
sMyString : string; //保留字,全部小写
hWindowsHandle : HWND; //Win32 API类型,全部大写
I : Integer; //在System单元中引用的类型标识,特定类型名

1.4.浮点型

通常情况下,对于浮点数应当使用Double,不鼓励使用Real类型,因为它只是为了与老的Pascal代码兼容而保留的。Double可被处理器优化,是IEEE定义的标准的数据格式。当需要比Double提供的范围更大时,可以使用Extend。

1.5.Variant和OleVariant

一般不建议使用Variant和OleVariant。但是,当数据类型只有在运行期才知道时(常常是在COM和数据库应用的程序中),这两个类型对编程就有必要。当进行诸如自动化ActiveX控件的COM编程时,应当使用OleVariant;而对于非COM编程,则应当使用Variant。这是因为,Variant能够有效地保存Delphi的原生字符串,而OleVariant则将所有字符串转换为OLE字符串(即WideChar字符串),且没有引用计数功能。

1.6.局部变量

局部变量用于过程内部,如果需要的话,应当在过程的入口处立即初始化变量。局部的AnsiString 类型的变量自动被初始化为空字符串,局部的接口和dispinterface类型的变量自动被初始化为nil,局部的Variant和OleVariant类型的变量自动被初始化为Unassigned。

1.7. 全局变量

一般不鼓励使用全局变量。不过,有时候需要用到。即使如此,也应当把全局变量限制在需要的环境中。例如,一个全局变量可能只在单元的实现部分是全局的。

全局数据如果将由许多单元使用,就应移动到一个公用单元里被所有对象使用。全局数据可在声明时直接初始化为一个值。注意,所有全局变量自动进行零初始化,因此,不要将全局变量初始化为诸如0 、nil、或Unassigned等空值。零初始化的全局变量在.EXE文件中不占空间。零初始化的数据保存在虚拟的数据段中,而虚拟数据段只在应用程序启动时才分配内存。非零初始化的全局数据则在.EXE文件中占空间。

1.8.if语句

在if/then/else语句中,最有可能执行的情况应放在then子句中,不太可能的情况放在else子句中。为了避免出现许多if语句,可以使用case语句代替。如果多于5级,不要使用if语句。请改用更清楚的方法。不要在if语句中使用多余的括号。

如果在if语句中有多个条件要测试,应按照计算的复杂程度从右向左排。这样,可以使代码充分利用编译器的短路估算逻辑。例如,如果Condition1比Condition2快,Condition2比Condition3快

1.9.case语句

case语句中每种情况的常量应当按数字或字母的顺序排列。每种情况的动作语句应当简短且通常不超过4 - 5 行代码。如果动作太复杂,应将代码单独放在一个过程或函数中。case语句的else子句只用于默认情况或错误检测。

1.10.while语句

建议不要使用Exit过程来退出while循环。如果需要的话,应当使用循环条件退出循环。所有对while循环进行初始化的代码应当位于while入口前,且不要被无关的语句隔开。任何业务的辅助工作都应在循环后立即进行。

1.11.for语句

如果循环次数是确定的,应当用for代替while语句

1.12.repeat语句。

repeat语句类似于while语句,且遵循同样的规则

1.13.with语句

with语句应该小心使用,要避免过度使用with语句,尤其是在with语句中使用多个对象或记录,例子

with Record1, Record2 do
begin
....
end;

   这些情况很容易迷惑编程人员,且导致调试困难

1.14.过程和函数

过程名或函数名应当以大写字母开头,且每个单词首字母大写,例如

procedure thisisapoorlyformattedroutinename;    //错误的写法,让人很难看明白
procedure ThisIsBetterProcedure; //这种写法更为易读

    只要有可能,同一类型的形参应当归并到一起,这样可以减少代码长度,例如:

procedure Foo(Param1:Imteger;Param2:Imteger;
Param3:Imteger;Param4:string); //不建议的用法
procedure Foo(Param1,Param2,Param3:Imteger;Param4:string); //建议的用法

   参数的顺序主要要考虑寄存器的调用规则,最常用的参数应该作为第一个参数,按照使用的频率以此从左到右,输入参数位于输出参数之前,范围大的参数应当在范围小的参数之前。也有例外,例如:在事件处理的过程中,TObject类型的Sender参数往往是第一个要传递的参数

1.15.常数参数

要使记录、数组、短字符串或接口类型的参数不能被过程修改,就应当把形参标以const 。这样,编译器将以最有效的方式生成代码,保证传递的参数不可变。

如果其他类型的参数希望不被过程所修改,也可以标上const 。尽管这对效率没有影响,但这给过程的调用者带来了更多的信息。

1.16.结构异常处理

异常处理主要用于纠正错误和保护资源。这意味着,凡是分配资源的地方,都必须使用try...finally来保证资源得到释放。不过,如果是在单元的初始/结束部分或者对象的构造器/析构器中来分配/释放资源是例外

1.17.try...finally的用法

可能的情况下,每个资源应当与try...finally结构匹配,例如错误的代码

SomeClass1 := TSomeClass.Create;
SomeClass2 := TSomeClass.Create; //此条语句出错时,SomeClass1无法释放
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;

    但是如果有许多类都需要同时创造,上述方案显得累赘,这时候建议使用下面的安全方案

SomeClass1 := nil;
SomeClass2 := nil;
try
  SomeClass1 := TSomeClass.Create;
  SomeClass2 := TSomeClass.Create;
  { do some code }
finally
  FreeAndNil(SomeClass1);
  FreeAndNil(SomeClass2);
end;

1.18.try...except的用法

如果你希望在发生异常时执行一些任务,可以使用try...except。通常,没有必要为了简单地显示一个错误信息而使用try...except,因为Application对象能够自动根据上下文做到这一点。如果要在子句中激活默认的异常处理,可以再次触发异常。

注意:一般情况下,原始的错误信息一般需要屏蔽掉不给用户看到,而是转换成我们自定义的更通俗易懂的描述给客户。但是原始的错误信息不能这样直接丢弃,否则,会给我们排查问题时带来较大的因难,所以一般需要记录下较详细的出错场景信息及原始出错信息,以备排查问题时使用。如果明确就是为了屏蔽某一类异常,可以不记录错误信息,但是这种情况慎用。例如:不当的用法:

sCount := ‘aaaa’;
try
iCount := StrToInt(sCount);
except
{ 转换出错数据是什么?为什么出错? 都不知道,这样给排查问题带来很大困难 }
ShowMessage(‘sCount转换类型失败!’);
end;

  正确的用法

sCount := ‘aaaa’;
try
iCount := StrToInt(sCount);
except
on e: Exception do
begin
WriteLog(‘sCount(当前值为:%s)转换类型失败!错误信息为:%s’,
sCount, e.message);
ShowMessage(‘sCount转换类型失败!’);
end;
end;