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

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

    这里先只介绍关于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;