|
ommentEvery source file should start with a block comment containing version information and a standard copyright notice. The version information should be in the following format:
{*******************************************************}
{ }
{ Widgets Galore }
{ }
{ Copyright (c) 1995,98 Your Company }
{ }
{*******************************************************}The copyright notice should contain at least the following line:
Copyright (c) yearlist CopyrightHolder.
If you are a third party creating a file for use by Borland, you may add your name at the bottom of the copyright notice: {*******************************************************}
{ }
{ Borland Delphi Visual Component Library }
{ Copyright (c) 1995,99 Borland International }
{ Created by Project JEDI }
{ }
{*******************************************************}
2.2.2 Unit declarationEvery source file should contain a unit declaration. The word unit is a reserved word, so it should be in lower case. The name of the unit should be in mixed upper and lowercase, and must be the same as the name used by the operating system''''s file system. Example:
unit MyUnit;
This unit would be called MyUnit.pas when an entry is placed in the file system.
2.2.3 uses declarations
Inside units, a uses declaration should begin with the word uses, in lowercase. Add the names of the units, following the capitalization conventions used in the declaration found inside the units: uses MyUnit;
Each unit must be separated from its neighbor by a comma, and the last unit should have a semicolon after it: uses
Windows, SysUtils, Classes, Graphics, Controls, Forms,
TypInfo;
It is correct to start the uses clause on the next line, as in the previous example, or you may start the list of units on the same line: uses Windows, SysUtils, Classes, Graphics, Controls, Forms,
TypInfo;
You may format the list of units in your uses clause so that they wrap just shy of 80 characters, or so that one unit appears on each line.
2.2.4 class/interface declarations
A class declaration begins with two spaces, followed by an identifier prefaced by a capital T. Identifiers should begin with a capital letter, and should have capital letters for each embedded word (InfixCaps). Never use tab characters in your Object Pascal source. Example: TMyClass
Follow the identifier with a space, then an equals sign, then the word class, all in lower case: TMyClass = class
If you want to specify the ancestor for a class, add a parenthesis, the name of the ancestor class, and closing parenthesis: TMyClass = class(TObject)
Scoping directives should be two spaces in from the margin, and declared in the order shown in this example:
TMyClass = class(TObject)
private
protected
public
published
end;
Data should always be declared only in the private section, and its identifier should be prefaced by an F. All type declarations should be four spaces in from the margin:
TMyClass = class(TObject)
private
FMyData: Integer;
function GetData: Integer;
procedure SetData(Value: Integer);
public
published
property MyData: Integer read GetData write SetData;
end;
Interfaces follow the same rules as class declarations, except you should omit any scoping directives or private data, and should use the word interface rather than class.
Naming Conventions
Except for reserved words and directives, which are in all lowercase, all Pascal identifiers should use InfixCaps, which means the first letter should be a capital, and any embedded words in an identifier should be in caps, as well as any acronym that is embedded: MyIdentifier
MyFTPClass
The major exception to this rule is in the case of header translations, which should always follow the conventions used in the header. For instance, write WM_LBUTTONDOWN, not wm_LButtonDown.
Except in header translations, do not use underscores to separate words. Class names should be nouns or noun phrases. Interface or class names depend on the salient purpose of the interface.
GOOD type names:
AddressForm, ArrayIndexOutOfBoundsException
BAD type names:
ManageLayout // verb phrase
delphi_is_new_to_me // underscores
3.1 Unit Naming
Use InfixCaps, as described at the beginning of this section. See also the section on unit declarations
3.2 Class/Interface Naming
Use InfixCaps, as described at the beginning of this section. Begin each type declaration with a capital T: TMyType See also the section on class/interface declarations.
3.3 Field Naming
Use InfixCaps, as described at the beginning of this section. Begin each type declaration with a capital F, and declare all data types in the private section, using properties or getters and setters to provide public access. For example, use the name GetSomething to name a function returning an internal field value and use SetSomething to name a procedure setting that value.
Do not use all caps for const declarations except where required in header translations.
Delphi is created in California, so we discourage the use of notation, except where required in header translations: CORRECT
FMyString: string;
INCORRECT
lpstrMyString: string;
The exception to the Hungarian notation rule is in enumerated types. TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkYes, bkNo, bkClose, bkAbort, bkRetry,
bkIgnore, bkAll);
In this case the letters bk are inserted before each element of this enumeration. bk stands for ButtonKind.
When thinking about naming conventions, consider that one-character field names should be avoided except for temporary and looping variables.
Avoid variable l ("el") because it is hard to distinguish it from 1 ("one") on some printers and displays.
3.4 Method NamingMethod names should use the InfixCaps style. Start with a capital letter, and capitalize the first letter of any subsequent word in the name, as well as any letters that are part of an acronym. All other characters in the name are lower case. Do not use underscores to separate words. Note that this is identical to the naming convention for non-constant fields; however it should always be easy to distinguish the two from context. Method names should be imperative verbs or verb phrases.
Examples:
// GOOD method names:
ShowStatus, DrawCircle, AddLayoutComponent
// BAD method names:
MouseButton // noun phrase; doesn''''t describe function
drawCircle // starts with lower-case letter
add_layout_component // underscores
// The function of this method is unclear. Does
// it start the server running (better: StartServer),
// or test whether or not it is running
// (better: IsServerRunning)?
ServerRunning // verb phrase, but not imperative
A method to get or set some property of the class should be called GetProperty or SetProperty respectively, where Property is the name of the property.
Examples:
GetHeight, SetHeight
A method to test some boolean property of the class should be called IsVisible, where Visible is the name of the property.
Examples:
IsResizable, IsVisible
3.5 Local Variable NamingLocal variables follow the same naming rules as field names, except you omit the initial F, since this is not a Field of an object. (see section 3.3).
3.6 Reserved Words
Reserved words and directives should be all lowercase. This can be a bit confusing at times. For instance types such as Integer are just identifiers, and appear with a first cap. Strings, however, are declared with the reserved word string, which should be all lowercase.
3.7 Type Declarations
All type declarations should begin with the letter T, and should follow the same capitalization specification laid out in the beginning of this section, or in the section on class declarations.
4.0 White Space Usage
4.1 Blank Lines
Blank lines can improve readability by grouping sections of the code that are logically related. A blank line should also be used in the following places:
- After the copyright block comment, package declaration, and import section.
- Between class declarations.
- Between method declarations.
4.2 Blank Spaces
Object Pascal is a very clean, easy to read language. In general, you don''''t need to add a lot of spaces in your code to break up lines. The next few sections give you some guidelines to follow when placing spaces in your code.
4.2.2 Blanks should not be used:
- Between a method name and its opening parenthesis.
- Before or after a .(dot) operator.
- Between a unary operator and its operand.
- Between a cast and the expression being cast.
- After an opening parenthesis or before a closing parenthesis.
- After an opening square bracket [ or before a closing square bracket ].
- Before a semicolon.
Examples of correct usage: function TMyClass.MyFunc(var Value: Integer);
MyPointer := @MyRecord;
MyClass := TMyClass(MyPointer);
MyInteger := MyIn上一页 [1] [2] [3] [4] 下一页
[系统软件]14.5.10.1 Object creation expressions [VB.NET程序]VB.Net中文教程(8) 对象(Object)基本概念
[Delphi程序]The Delphi Object Model (PART III) [Delphi程序]The Delphi Object Model (PART II)
[Delphi程序]The Delphi Object Model (PART I) [Delphi程序]Object Pascal：从对象指针谈起
[Delphi程序]浅谈Object Pascal的指针 [Delphi程序]kmp模式匹配算法的pascal实现
[Delphi程序]Object TreeView简要说明 [Delphi程序]Pascal 精要--第一章
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
