Examples of incorrect usage:

function TMyClass.MyFunc( var Value: Integer ) ;
MyPointer := @ MyRecord;
MyClass := TMyClass ( MyPointer ) ;
MyInteger := MyIntegerArray [ 5 ] ;

4.3 Indentation

You should always indent two spaces for all indentation levels. In other words, the first level of indentation is two spaces, the second level four spaces, the third level 6 spaces, etc. Never use tab characters.

There are few exceptions. The reserved words unit, users, type, interface, implementation, initialization and finalization should always be flush with the margin. The final end statement at the end of a unit should be flush with the margin. In the project file, the word program, and the main begin and end block should all be flush with the margin. The code inside the begin..end block, should be indented at least two spaces.

4.4 Continuation Lines

Lines should be limited to 80 columns. Lines longer than 80 columns should be broken into one or more continuation lines, as needed. All the continuation lines should be aligned and indented from the first line of the statement, and indented two characters. Always place begin statements on their own line.

Examples:

// CORRECT

function CreateWindowEx(dwExStyle: DWORD; 
  lpClassName: PChar; lpWindowName: PChar; 
  dwStyle: DWORD; X, Y, nWidth, nHeight: Integer;
  hWndParent: HWND; hMenu: HMENU; hInstance: HINST; 
  lpParam: Pointer): HWND; stdcall;

// CORRECT 

if ((X = Y) or (Y = X) or
  (Z = P) or (F = J) then
begin
  S := J;
end;

Never wrap a line between a parameter and its type, unless it is a comma separated list, then wrap at least before the last parameter so the type name follows to the next line. The colon for all variable declarations contains no whitespace between it and the variable. There should be a single space following the colon before the type name;

// CORRECT

procedure Foo(Param1: Integer; Param2: Integer);

// INCORRECT

procedure Foo( Param :Integer; Param2:Integer );

A continuation line should never start with a binary operator.[???] Avoid breaking a line where normally no white space appears, such as between a method name and its opening parenthesis, or between an array name and its opening square bracket. If you must break under these circumstances, then one viable place to begin is after the opening parenthesis that follows a method name. Never place a begin statement on the same line with any other code.

// INCORRECT
while (LongExpression1 or LongExpression2) do begin
  // DoSomething
  // DoSomethingElse;
end;

// CORRECT
while (LongExpression1 or LongExpression2) do 
begin
  // DoSomething
  // DoSomethingElse;
end;

// CORRECT
if (LongExpression1) or 
  (LongExpression2) or 
  (LongExpression3) then 
  

5.0 Comments

The Object Pascal language supports two kinds of comments: block, and single-line comments. Some general guidelines for comment usage include:

• It is helpful to place comments near the top of unit to explain its purpose.
• It is helpful to place comments before a class declaration.
• It is helpful to place comments before some method declarations.
• Avoid making obvious comments:

i := i + 1;	// Add one to i

• Remember that misleading comments are worse than no comments at all.
• Avoid putting any information into comments that is likely to become out of date.
• Avoid enclosing comments in boxes drawn with asterisks or other special typography.
• Temporary comments that are expected to be changed or removed later should be marked with the special tag "???:" so that they can easily be found afterwards. Ideally, all temporary comments should have been removed by the time a program is ready to be shipped.

Example:

// ???: Change this to call Sort when it is fixed
List.MySort;

5.1 Block Comments

Object Pascal supports two types of block comments. The most commonly used block comment is a pair of curly braces: { }. The Delphi team prefers to keep comments of this type as spare and simple as possible. For instance, you should avoid using asterisks to create patterns or lines inside your comments. Instead, make use of white space to break your comments up, much as you would in a word processing document. The words in your comments should start on the same line as the first curly brace, as shown in this excerpt from DsgnIntf.pas:

{ TPropertyEditor

  Edits a property of a component, or list of components, 
  selected into the Object Inspector.  The property 
  editor is created based on the type of the
  property being edited as determined by the types 
  registered by...
  
  etc...
  
    GetXxxValue
      Gets the value of the first property in the 
      Properties property.  Calls the appropriate 
      TProperty GetXxxValue method to retrieve the 
      value. 
      
    SetXxxValue Sets the value of all the properties 
      in the Properties property.  Calls the appropriate 
      TProperty SetXxxxValue methods to set the value. }

A block comment is always used for the copyright/ID comment at the beginning of each source file. It is also used to "comment out" several lines of code.

Block comments used to describe a method should appear before the method declaration.

Example:

// CORRECT

{ TMyObject.MyMethod
   
  This routine allows you to execute code. }

procedure TMyObject.MyMethod;
begin
end;

// INCORRECT

procedure TMyObject.MyMethod;
{******************************************************
  TMyObject.MyMethod
   
  This routine allows you to execute code. 
*******************************************************}
begin
end;

A second kind of block comment contains two characters, a parenthesis and an asterisk: (* *). This is sometimes called starparen comments. These comments are generally useful only during code development, as their primary benefit is that they allow nesting of comments, as long as the nest level is less than 2. Object Pascal doesn''''t support nesting comments of the same type within each other, so really there is only one level of comment nesting: curly inside of starparen, and starparen inside of curly. As long as you don''''t nest them, any other standard Pascal comments between comments of this type will be ignored. As a result, you can use this syntax to comment out a large chunk of code that is full of mixed code and comments:

(* procedure TForm1.Button1Click(Sender: TObject);
begin
  DoThis; // Start the process
  DoThat; // Continue iteration
  { We need a way to report errors here, perhaps using
    a try finally block ??? }
  CallMoreCode; // Finalize the process
end; *)

In this example, the entire Button1Click method is commented out, including any of the subcomments found between the procedure''''s begin..end pair.

5.2 Single-Line Comments

A single-line comment consists of the characters // followed by text. Include a single space between the // and the comment itself. Place single line comments at the same indentation level as the code that follows it. You can group single-line comments to form a larger comment.

A single-line comment or comment group should always be preceded by a blank line, unless it is the first line in a block. If the comment applies to a group of several statements, then the comment or comment group should also be followed by a blank line. If it applies only to the next statement (which may be a compound statement), then do not follow it with a blank line.

// Open the database
Table1.Open;

Single-line comments can also follow the code they reference. These comments, sometimes referred to as trailing comments, appear on the same line as the code they describe. They should have at least one space-character separating them from the code they reference. If more than one trailing comment appears in a block of code, they should all be aligned to the same column.

if (not IsVisible) then
  Exit;          // nothing to do
Inc(StrLength);  // reserve space for null terminator

Avoid commenting every line of executable code with a trailing comment. It is usually best to limit the comments inside the begin..end pair of a method or function to a bare minimum. Longer comments can appear in a block comment before the method or function declaration.

Classes

6.1 Class Body Organization

The body of a class declaration should be organized in the following order:

• Field declarations
• Method declarations
• Property declarations

The fields, properties and methods in your class should be arranged alphabetically by name.

6.1.1 Access levels

Except for code inserted by the IDE, the scoping directives for a class should be declared in the following order:

• Private declarations
• Protected declarations
• Public declarations
• Published declarations

There are four access levels for class members in Object Pascal: published, public, protected, and private -- in order of decreasing accessibility. By default, the access level is published. In general, a member should be given the lowest access level which is appropriate for the member. For example, a member which is only accessed by classes in the same unit should be set to private access. Also, declaring a lower access level will often give the compiler increased opportunities for optimization. On the other hand, use of private makes it difficult to extend the class by sub-classing. If there is reason to believe the class might be sub-classed i

上一页  [1] [2] [3] [4]  下一页