Delphi programmer code preparation standard guide

zhaozj2021-02-17  51

COPY from

First, preamble

Second, universal source code format rules

2.1 格

2.2 page space

2.3 Begin ... END pairing

Third, Object Pascal3.1 Brand

3.2 Reserved words and keywords

3.3 Processes and Functions (routines)

3.3.1 Name / Format

3.3.2 Formal parameters

3.3.2.1 Format

3.3.2.2 Named

3.3.2.3 Sort by parameter

3.3.2.4 Constant parameters

3.3.2.5 Conflicts of the name

3.4 variables

3.4.1 Names and format of variables

3.4.2 Local variables

3.4.3 Use of global variables

3.5 Type

3.5.1 Understanding

3.5.1.1 Floating point pointer type

3.5.1.2 Enumeration Type

3.5.1.3 Variables and OLE variable types

3.5.2 Structure Type

3.5.2.1 Array Type

3.5.2.2 Recording Type

3.6 statement

3.6.1 IF statement

3.6.2 CASE statement

3.6.2.1 General Topics

3.6.2.2 Format

3.6.3 WHILE statement

3.6.4 for statement

3.6.5 REPEAT statement

3.6.6 With statement

3.6.6.1 General Topics

3.6.6.2 format

3.7 Structure abnormal processing

3.7.1 General Topics

3.7.2 Try ... Finally used

3.7.3 Try ... Except

3.7.4 Try ... Except ... Else

3.8 type type

3.8.1 Names and format

3.8.2 domain

3.8.2.1 Named / Format

3.8.2.2 Visualization

3.8.3 Method

3.8.3.1 Named / Format

3.8.3.2 Use Static Method

3.8.3.3 Using Virtual / Dynamic Method

3.8.3.4 Using Abstract Methods

3.8.3.5 Property Access Method

3.8.4 Property

3.8.4.1 Named / Format

3.8.4.2 Methods Using Access

Four, documents

4.1 Engineering Document

4.1.1 Name

4.2 Form file

4.2.1 Name

4.3 Data Template File

4.3.1 Name

4.4 remote data template file

4.4.1 Name

4.5 Unit file

4.5.1 Universal Unit Structure

4.5.1.1 Name of Unit

4.5.1.2 Uses clause

4.5.1.3 Interface section

4.5.1.4 Part IMPLEMENTATION section

4.5.1.5 Initialization section

4.5.1.6 Finalization section

4.5.2 Form Unit

4.5.2.1 Name

4.5.3 Data Template Unit

4.5.3.1 Name

4.5.4 General destination unit

4.5.4.1 Named

4.5.5 Component Unit

4.5.5.1 Name

4.6 file header

V. Forms and data templates

5.1 Form

5.1.1 Form Type Name Standard

5.1.2 Form instance naming standard

5.1.3 Automatically create a form

5.1.4 Mode Form Instantiation Function

5.2 Data Template

5.2.1 Data Template Naming Standard

5.2.2 Data Template Instance Name Standard

Sixth, package

6.1 Comparison of running packages and design packages

6.2 file naming standard

Seven, component

7.1 User Customizing Components

7.2 component unit

7.3 Using registration unit

7.4 Component instance naming conventions

7.5 Prefix of the component

7.6 Standard Page

7.7 Additional Page

7.8 Win32 Page

7.9 SYSTEM Page

7.10 Internet Page

7.11 Data Access Page

7.12 Data Controls Page

7.13 Decision Cube Page

7.14 QReport Page

7.15 Dialogs Page

7.16 Win3.1 Page

7.17 Samples Page

7.18 ActiveX Page

7.19 Midas Page

Delphi 4 Programmer Code Writing Standard Guide Copyright 1998 Xavier Perchad and Steve Teiseira

I. Prospect 2, universal source code format rule 2.1 Dibrant 2.2 Page Space 2.3 Begin ... END pairing three, Object Pascal3.1 Brand 3.2 Reserved Words and Keywords 3.3 Processes and Functions (routines)

3.3.1 Naming / Format 3.3.2 Form Parameters 3.3.2.1 Format 3.3.2.2 Name 3.3.2.3 Sorting 3.3.4 Constant Parameters 3.3.2.4 Conflict 3.4 Variables 3.4.1 Names and Format of Variables 3.4. 2 Local variables 3.4.3 Global variables 3.5 Type 3.5.1 capitalization agreed 3.5.1.1 Floating point pointer type 3.5.1.2 Enumeration Type 3.5.1.3 Variables and OLE Variable Type 3.5.2 Structure Type 3.5.2.1 Arrange Type 3.5. 2.2 Recording Type 3.6 Statement 3.6.1 IF Statement 3.6.2 Case Statement 3.6.2.1 General Topic 3.6.2.2 Format 3.6.3 While Statement 3.6.4 for Statement 3.6.5 REPEAT Statement 3.6.6 with Statement 3.6.6.1 General Topics 3.6.6.2 Format 3.7 Structure Abnormal Processing 3.7.1 General Topics 3.7.2 Try ... Finally 3.7.3 Try ... Except ... 3.7.8 Try ... Except ... Else 3.8 Type 3.8.1 Name and format 3.8. 2 domain 3.8.2.1 Named / Format 3.8.2.2 Visualization 3.8.3 Method 3.8.3.1 Name / Format 3.8.3.2 Using Static Method 3.8.3.3 Methods Using Virtual / Dynamic 3.8.3.4 Working with Abstract 3.8.3.5 Property Take Method 3.8.4 Property 3.8.4.1 Name / Format 3.8.4.2 Using Acquisition Method 4, File 4.1 Project Document 4.1.1 Name 4.2 Form file 4.2.1 Name 4.3 Data Template file 4.3.1 Name 4.4 remote data Template file 4.4.1 Name 4.5 Unit file 4.5.1 Universal Unit Structure 4.5.1.1 Uni Name 4.5.1.2 Uses clause 4.5.1.3 Interface section 4.5.1.4 Implementation section 4.5.1.5 Initialization section 4.5.1.6 Finalization section 4.5.2 Form unit 4.5.2.1 Name 4.5.3 Data Template Unit 4.5.3.1 Name 4.5 .4 General destination unit 4.5.4.1 Name 4.5.5 Component Unit 4.5.5.1 Named 4.6 File Head 5, Forms and Data Templates 5.1 Form 5.1.1 Form Type Naming Standard 5.1.2 Form Instance Naming Standard 5.1.3 Automatic creation of form 5.1.4 Mode Forms 5.2 Data Templates 5.2.1 Data Template Naming Standard 5.2.2 Data Template Instance Name Standard Six, Package 6.1 Comparison 6.2 File Name Standard Seven, Comparison 7.1 User Custom Members 7.2 Members 7.3 Using Registration Unit 7.4 Components Instance Answerings 7.5 Compound 7.6 Standard Page 7.7 Additional Page 7.8 WIN32 Page 7.9 System Page 7.10 Internet Page 7.11 Data Access Page 7.12 Data Controls Page 7.13 Decision Cube 7.14 QReport Page 7.15 Dialogs Page 7.16 WIN3.1 Page 7.17 Samples Page 7.18 ActiveX Page 7.19 Midas Page 1, Preface

This document details the code written standard for programming under the Delphi 4 Developer Guide. Under normal circumstances, this document follows the guidelines of the "cancel" format, which is used by Borland International. In the Delphi 4 Developer Guide, the purpose of this document is to illustrate a method. By this method, the development team can maintain a consistent style in the code they have. The purpose of this is to make each programmer in the development group can understand the code of other programmers. This helps to increase the conception and use of code written. This document does not mean all standards existing in the code. However, its content is enough to help you get a good head. You can add these criteria to meet your needs. We don't agree that you have deviated from these standards used by Borland developers too far. We recommend this because there is a new programmer to join your development team, and their favorite and most familiar is Borland's standard. This document will also be changed as needed in most code standard documents. So you can find the latest update version in www.xapware.com/ddg. This document does not include the user interface standard. This document is independent but equally important. There is already enough third-party books and Microsoft documents including some other guidelines, and we decide not to copy this information, but we will guide you to Microsoft Developers Network and some resources, where you can find what you need.

Second, universal source code format rules

2.1 格

The minus finger refers to two spaces at each level. Do not keep TAB characters in the source code, because Tab characters represent different widths with different settings of different users and different resource management tools (print, document, version control, etc.).

You can prevent saving Tab characters from the "Use Tab Character" and "Optimal Fill" check box on the Editor page in the Environment Options dialog box (via Tools | Environment).

2.2 page space

The page space will be set to 80 characters wide. Usually, the source code will not exceed this boundary, but this policy will have some flexibility. Regardless of whether it is possible, those statements that exceed another line will be connected to the previous statements after a comma or other operator. When a statement is interrupted, it should indumb to two characters than the original line statement.

2.3 Begin ... END pairing

The Begin clause should be written in an independent line. For example, the first line below is the wrong way of writing and the second line is correct. For i: = 0 to 10 do begin file: // error, Begin with for i: = 0 to 10 do file: // correct, Begin appears in a separate line of Begin

The exception of this rule is part of the Begin clause as part of an else clause - Reference example: if Some Statement thenbegin ... endelse begin sometherstatement;

The end statement will always appear in an independent line. When the Begin statement is not part of an ELSE clause, the corresponding End statement is always indentation to a location corresponding to the Begin section.

Third, Object Pascal

3.1 Brand

Never leave spaces in the middle of the characters between brackets and brackets. The following example demonstrates erroneous and spaces in parentheses: CallProc (APARETER); file: // Error CallProc (APARETER); file: // correct

Never use unnecessary parentheses in a statement. Brackets should only be used in places they need in the source code. The following example demonstrates errors and correct use: if (i = 42) THEN FILE: // Error - Excess parentheses IF (i = 42) or (j = 42) THEN FILE: // correct - need brackets 3.2 Reserved Words and keywords

Object Pascal reserves the words and keywords are always lowercase.

3.3 Processes and Functions (routines)

3.3.1 Name / Format

The name of the routine will never start with uppercase letters and is distinct to be readable. Below is a process name in incorrect format: Procedure thisisapoorlyformattedRoutinename;

Here is an example of a suitable case routine name: Procedure thisismuchmorereadableRoutinename;

The name of the routine should be consistent with its content. A routine that can lead to a behavior should begin with the verb. ,, For example: Procedure Formatharddrive;

A routine for setting the input parameters should be prefixed as a word set, for example: procedure setUsername;

A routine used to receive a value should be prefixed as a word GET, for example: Procedure getUsename: string;

3.3.2 Formal parameters

3.3.2.1 Format

If there is, the same type of shape is merged in a statement: Procedure Foo (Param1, Param2, Param3: Integer; param4: string);

3.3.2.2 Named

The names of all ginseng should be very in line with the significances they represent, especially in the name of the flag transmitted to the routine. A good parameter name should be prefixed in character A - for example: procedure someproc (ausername: string; meansERAGE: Integer);

"A" prefix is ​​set by the presentation that the name of this parameter is corresponding to one of the types of properties or domains in the class type.

3.3.2.3 Sort by parameter

The order of the above-mentioned meticulum focuses on the benefits of the registrant call convention call.

- The most common parameters should be placed first, and other parameters should be arranged in the order from left to right. - The input parameter list should be placed on the left of the output parameter list. - Place the general parameters on the left side of the special parameters, for example: Procedure SomeProc (Aplanet, ACONTINENT, ACOUNTRY, ASTATE, ACITY) - Sort may be some exception, such as the process of the event. The Sender parameter for TOBJECT is often placed first.

3.3.2.4 Constant parameters

These parameters should be tagged when a parameter is a record type, array type, shortstring, or interface type and when it is not changed in routines. This will make the compiler more efficiently generate code related to these non-changing parameters.

Other non-variable parameters in the routine can also be transmitted. Although there is no effect and improve efficiency, this will provide more information to the user of the modified routine.

3.3.2.5 Conflicts of the name

When two units with the same routine with two names, if you call this routine, the routines in the end of the unit in the Uses clause will be called. To solve this "blur" conflict in the USES clause "conflict, you must write the prefix of the associated cells when calling the routine, for example: sysutile.findclose (SR); or Windows.FindClose (Handle);

3.4 variables

3.4.1 Names and format of variables

Naming of variables should be consistent with their purpose

The loop control variable should be used as a name, such as I, J, or K, or more meaningful names, such as UserIndex.

The name of the logical variable should be able to fully express the meaning of accurate or false.

3.4.2 Local variables

The local variables in a process should follow the usage and naming conventions of all other variables. Temporary variables should be reasonable.

If necessary, the partial variable should be initialized in one entry routine. The local ANSISTRING variable will automatically initialize an empty string. Local interface and distribution interface type variable will automatically initialize the NIL, and local variables and OLE variable type variables will automatically initialize to unassigned

3.4.3 Use of global variables

It is not recommended to use global variables. However, it is still necessary to use at some time, and they should only be used when they must be used. At this time, you should work hard to use global variables within a context. For example, a global variable should only be globally located in the IMPLEMNTATION section of a unit. If you intend to use global data in multiple unit classes, you should move them into a common unit and then used by all other units.

Global variables can be initialized to a value directly in a VAR clause. Remember, all global data will automatically initialize 0, so do not initialize global variables to a "empty" value such as 0, nil, '', unassigned, and so on. One reason why this is because zero-initialization global data will not occupy any space in the EXE file. Zero - Initialization Data is stored in a virtual data segment, which is assigned in a period of memory after the application is started. Non-zero-initialized global data takes up in the exe file of the hard disk.

3.5 Type

3.5.1 Understanding

If the name of the name is a reserved word, then it should be written. Win32 API types are usually all capitalized and you must follow the agreement of the detailed type name in Windows.PAS or other API units. For other variable names, one letter should be uppercase, and other letters should be missed. Here are some examples: var myString: String; file: // Reserved Word WindowHandle: HWnd; File: // Win32 API Type I: Integer; File: // Introduced Type Identifier Introduced in System Unit

3.5.1.1 Floating point pointer type

Real types are not recommended because it exists just to compatibility with early Pascal code. In normal cases, use Double to implement the needs of floating point pointers. And, Double is optimized for the processor and bus, and it is also the standard data format defined in the IEEE. Extended is only used when the range is required to exceed the range defined by Double. Extended is the type of Intel definition and does not support in Java. Single is only used when the actual byte size of the floating point pointer variable has its meaning. (, For example, when using another language DLLS).

3.5.1.2 Enumeration Type

The name of the enumeration type needs to be in accordance with the purpose of this type. This type of name needs to be prefixed in character T to indicate that this is a type. The identifier list in the enumeration type must contain two or three characters of the prefix corresponding to the name of the enumeration type - for example: tsongtype = (Strock, StClassical, StCountry, Stalternative, StheavyMetal, StrB); an enumeration type The name of the instance should be the same as the enumeration type of not prefix, unless there is a better reason to give this variable more special name, such as FavoritesongType1, FavoritesongType2, etc.

3.5.1.3 Variables and OLE variable types

Variables and OLE variable types are usually not recommended. However, this type must be used in programs that only have time to know the data type, which appears in COM and database development. OLE variables are used in COM-based programming, such as automation and ActiveX control, and variables are used in non-COM programming, because variables can store local Delphi strings (same as the same string variable) in the same variable, but The OLE variable converts all strings to an OLE string (WideChar string) and does not instance - they will be copied forever. 3.5.2 Structure Type

3.5.2.1 Array Type

The name of the array type needs to meet the purpose of use. The name of this type must be prefix T. If the array type pointer is required, then the pointer needs to be prefixed and should be immediately declared in front of the array declaration. For example: Type PcycleArray = ^ TcycleArray; TcycleArray = array [1 ... 100] of integer; in practical applications, the name of the variable instance of the array should be the name of its type to remove the prefix T.

3.5.2.2 Recording Type

The name of the record type should meet the purpose of using them. Its type of statement should be prefix T. If you want to declare the pointer of the record type, it should be prefixed and should close to the previous declaration of the type declaration. For example: Type Pemployee = ^ Temployee; TemPloyee = Record Employeename: String; EMPLOYEERATE: DOUBLE;

3.6 statement

3.6.1 IF statement

The most frequently occurred behavior in the IF / THEN / ELSE statement is placed in the Then clause, while other behaviors that have less likely to be placed in the ELSE clause.

Try to avoid using nested IF statements, using multiple IF statements in this case to judge various possibilities.

Do not use the IF nested more than five depths. The code should be written clearer and clear.

Do not use unnecessary parentheses in the IF statement.

If there are multiple conditions in the IF statement to be tested, these conditions should be arranged from left to right from left to right by less than a few order. Doing so allows the compiler to get the shortcut of Boolerance when compiling code, making your code best optimization. For example, if the condition 1 is faster than condition 2, the condition 2 is faster than the condition 3, then the arrangement in the IF statement should be: IF condition 1 AND condition 2 AND condition 3 THEN

3.6.2 CASE statement

3.6.2.1 General Topics

Each independent unit in a CASE statement should be arranged in a number or alphabetical order.

The action behavior of each CASE unit should be simple and should not exceed four to five lines. If the action you want is too complex, a separate process or function should be used.

The else clause in the CASE statement is only used when the default behavior is required or handled.

3.6.2.2 Format

The CASE statement should follow other structural division and naming conventions.

3.6.3 WHILE statement

In a While statement, it is not recommended to use the EXIT procedure to jump out of the loop, try to use only cyclic conditions to jump out of the loop.

The initialization code used in a While cycle should close to the WHILE cycle, not being separated by other unrelated statements.

Any end process should be carried out immediately after the loop.

3.6.4 for statement

The FOR statement can only replace the While statement when the number of cycles is known.

3.6.5 REPEAT statement

The REPEAT statement is the same as the While statement and follows the same general policy.

3.6.6 With statement

3.6.6.1 General Topics

The WITH statement should save use and have a lot of warnings. Avoid excessive use of the with statement and use multiple objects, records, and more in the WITH statement. For example: with record1, Record2 Do these things will make programmers feel confused and difficult to find out. 3.6.6.2 format

The WITH statement follows the format rules for naming conventions and minibo indicated by this document.

3.7 Structure abnormal processing

3.7.1 General Topics

Abnormal processing is used in large quantities of error correction and resource protection. That is to say that once the resource is assigned, a try ... finally must use to ensure that the resource is released correctly. This anomalous protection also refers to the allocation and release of resources in a unit's Initialization / Finalization or an object's constructor / design.

3.7.2 Try ... Finally used

In any case, every assignment should follow a try ... finally. For example, the following code will result in possible errors: someclass1: = tsomeclass.create; someclass2; = tsomeclass.create; tryally someclass1.free; someclass2.free; end;

A more secure and more suitable allocation process should be: someclass1: = tsomeclass.create; try somclass2: = tsomeclass.create; tryally someclass2.free; end; fin or someclass1.free; end;

3.7.3 Try ... Except

Only use try ... excepts when they are triggered and you want to perform some tasks. Usually, you don't have to use the Try ... Except statement in order to display an error message simply on the screen, because this will be automatically executed by the Application object. If you want to call the default exception handler after performing some tasks in the Except clause, use Raise to re-trigger an exception to the next handle.

3.7.4 Try ... Except ... Else

The else clause in Try ... Except is not recommended because it interrupts all exceptions including those you are not prepared.

3.8 type type

3.8.1 Names and format

The name of the class type should meet the purpose of using them. Type names should be prefixed to indicate that this is a type of definition - for example: type tcustomer = class (TOBJECT) type instance is usually the name of the type of the prefix T, for example: VAR Customer: Tcustomer; Note: Review "Component Type Naming Standards to get more information about the component named.

3.8.2 domain

3.8.2.1 Named / Format

The domain name of the class follows the same agreed with the variable identifier, except that they should be prefixed in F, indicating that this is the name of a domain.

3.8.2.2 Visualization

All domains must be private. Want to access the domain outside the class to use attributes.

3.8.3 Method

3.8.3.1 Named / Format

The naming of the method should follow the procedures and functions of this document.

3.8.3.2 Use Static Method

If a static method is used, then this method cannot be inherited by the descendum of the class.

3.8.3.3 Using Virtual / Dynamic Method

If you intend to use the method of this class, you can use the virtual method if you are inherited by the proceedings. A dynamic method is only used when the method has multiple inherits (direct or indirect). For example, a class type contains a can inherit, and 100 descendants should inherit this method, then this method dynamically generates the memory used by 100 descendants. 3.8.3.4 Using Abstract Methods

If you use an abstract method in a class, this class cannot be created. Only use abstract methods in classes that never be created.

3.8.3.5 Property Access Method

All access classes can only appear in the Private or Protaced section of the class. Naming of attribute access methods should follow the process and function's agreed rules. Read Access Method (Method Reader) must be prefixed with a word GET. Writing Access Method (Method Writer) must be prefixed in word Set. Method The name of the parameter of the writer should be Value, and its type should be the type of attribute it operate. For example: 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 Property

3.8.4.1 Named / Format

The attribute If it is an accesser representing a private domain, then its name should be the name of the domain they operate to remove the explanatory F.

The name of the attribute should be a noun, not a verb. The attribute is indicated by data, and the method is represented by behavior.

The name of the array type should be a plural. In general, the name of the attribute should be singular.

3.8.4.2 Methods Using Access

Although there is no requirement, it is recommended to use a write access method as possible as possible for a private domain attribute.

Four, documents

4.1 Engineering Document

4.1.1 Name

The project document should take a descriptive name. For example, the project name of the Delphi 4 Developer Guide Error Manager is: DDGBUGS.DPR. The name of a program related to system information should be like sysinfo.dpr.

4.2 Form file

4.2.1 Name

Name of a form file should be able to describe the purpose of using the form and suffix FRM. For example, a file name of a "about" form should be AboutFrm.dpr. The file name of the main form should be mainfrm.dpr.

4.3 Data Template File

4.3.1 Name

The name of the data template should be able to represent the purpose of using the data template, and its name should be added two characters of the suffix DM. For example, the file name of the custom data template should be CUSTOMERSDM.DFM.

4.4 remote data template file

4.4.1 Name

The name of the remote data template should be able to represent the purpose of using the remote data template, and its name should be the suffix RDM of three characters. For example, the file name of the custom distal data template should be CustomersRDM.DFM.

4.5 Unit file

4.5.1 Universal Unit Structure

4.5.1.1 Name of Unit

A Unit file should take a descriptive name. For example, the unit containing the application main form should be called mainfrm.pas.

4.5.1.2 Uses clause

The USES clause at the interface section should be included in the unit required in the interface section. Remove those Delphi to automatically join the unit in the program.

The USES clause in the Implementation section should only contain the name of the unit required for the code required in the IMplementation section. Remove unnecessary units.

4.5.1.3 Interface section

The Interface section should contain only those definitions, variables, process / functions of the access types that other units, and the like. Otherwise, it should be placed on the Implementation section.

4.5.1.4 Implementation section Part IMplementation section should include those type definitions, variables, procedures / function definitions, etc. that are only private in this unit.

4.5.1.5 Initialization section

Don't put the time-long code in the Initialization section, which will make the first interface of the program slower.

4.5.1.6 Finalization section

Here you must ensure that you release any resource you assigned to the Initialization section.

4.5.2 Form Unit

4.5.2.1 Name

The unit file of a form should have the same name as the form file it corresponds. For example, the unit name of the "About" form should be AboutFrm.PAS, while the unit name of the main form should be Mainfrm.PAS.

4.5.3 Data Template Unit

4.5.3.1 Name

The unit file of a data template should have the same name as the data template file it corresponds. For example, the name of a custom data template unit should be Customersdm.PAS.

4.5.4 General destination unit

4.5.4.1 Named

The name of the general purpose unit should meet the purpose of using the unit. For example, a utility unit is named bugutilities.pas. A unit containing global variables is named Customerglobals.PAS.

Note that the name of the unit cannot be the same as the name of the unit in all packets used in its work. Not approved with general or universal unit names.

4.5.5 Component Unit

4.5.5.1 Name

The component unit should be placed in a separate catalog to distinguish them in distinguishing between units or components set. They should always be in different directories. The unit name should be consistent with their content.

Note: Check the "User-Defined Component" section to get more information about component naming standards.

4.6 file header

It is recommended to use an information file header in all source files, project files, units, and the like. A good file header should contain the following information: {copyright ... the year, month, day ...}

V. Forms and data templates

5.1 Form

5.1.1 Form Type Name Standard

The name of the form type should be able to express the purpose of using the form. Type definition should be prefix T. The prefix followed by the descriptive name. Finally, a Form suffix should be applied to describe the name. For example, the name of the type of "About" form should be: TaboutFrom = Class (TForm); the main form is defined as: TMAINFORM = Class (TFORM); a user access form should be image: tcustomerentryform = Class (TForm);

5.1.2 Form instance naming standard

The form instance should be the name of the corresponding class with a prefix T. For example, the name of the example should be: corresponding to the previous form type.

Type Name Instist Name Taboutform Aboutform Tmainform Mainform TcustomerentryForm Customerentryform

5.1.3 Automatically create a form

Only the main form can be automatically created unless otherwise better reasons do not do so. All other forms must be removed from the automatic creation list in the Engineering Options dialog box. Check out the following sections to get more information.

5.1.4 Mode Form Instantiation Function

All form units should contain a form instantiation function, which is used to create, set, modely display the form, and release the form. This function should return the pattern of the form. The parameters you want to pass should follow the "Parameter Pass" standard specified by this document. The functionality packaged in this way helps the reuse and maintenance of the code.

The variable of the form is to be removed from the unit, and a local definition is performed in a function of the form. Note that this means that the form must be removed from the automatic creation list in the Project / Options dialog. Refer to "Automatically Create Form" later in this document.

For example, the unit below shows a function in the GetUserData form. unit UserDataFrm; interface useswindows, 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 Data Template

5.2.1 Data Template Naming Standard

The name of the data template should meet the purpose of using the data template. The definition of the type should be prefeded T, followed by the descriptive name, and finally add the debug word "Datamodule". For example, a custom data template is sometimes like: tcustomerDataModule = Class (TDataModule) A manual data template name: TordersDataModule = Class (TDataModule)

5.2.2 Data Template Instance Name Standard

The name of the data template instance should be the name of the type that does not have a prefix T. For example, for the previous form type, the name of the example should be: Type Name Example Name TcustomerDataModule CustomerDataModule TordersDataModule ORDERSDATAMODULE

Sixth, package

6.1 Comparison of running packages and design packages

The outline of the runtime should only contain the units or components required for other component packages. Additionally, the included attribute / component editor and other code to be designed should be placed in the design timing package. The registration unit should be placed in the design package.

6.2 file naming standard

The name of the package should be followed by: "IILIBVV.PKG" - Design Time Package "IiistDv.pkg" - Running Close Bracket Character "III" indicates a 3-character identification prefix. This prefix is ​​used to indicate companies, individuals, or other identified entities.

Character "VV" is represented as the version number of the package that you want to correspond to a version of Delphi.

Note that the name of "lib" or "std" in the name of the package is to indicate that this is a design time package or a runtime package.

If it is both a design time package and a runtime package, the name of the file is the same above, for example, the name of the package made for the Delphi 4 Developer Guide should be:

DDGLIB40.PKG - Design Time Bag DDGSTD40.PKG - Running Package

Seven, component

7.1 User Customizing Components

The name of the component named in the standard component is defined as a class type as the "class type" section definition, and the difference is that they have a 3-character indicator prefix, which can represent companies, individuals, or other entities. For example, a name of a clock component written for a Delphi 4 Developer Guide is defined as: TDDGCLOCK = Class (TComponent) Note that the three prefix characters are lowercase.

7.2 component unit

The component unit should contain only one primary member, and a major component is a component in the component column. The auxiliary member / object of the main component should be placed in the same unit.

7.3 Using registration unit

The registration process of the component should be removed from the unit itself and put it into a separate unit. This registration unit can be used to register any component, attribute editor, component editor, exemption, etc.

The registration of the component should only be carried out in the design clip, and the registration unit should be included in the design time package and should not be placed in the running moment.

The name of the registration unit recommended is: 3 prefix characters "XXX" above XXXREG.PAS is used to represent a company, individual or any other entity. For example, the name of the registration unit in the Delphi 4 Developer Guide should be DDGREG.PAS.

7.4 Component instance naming conventions

All components should take a descriptive name. The components of the default name created by Delphi are not abandoned. A lowercase prefix should be designed when the design component type is designed. The reason why the prefix does not use the suffix is ​​when searching, the name of the search component in the Object Check and the Code Explorer is more easily implemented than the type of search member.

7.5 Prefix of the component

The prefix of the following components can be used to design the standard components in Delphi 4. Please join the prefix of a third party component in this list.

7.6 Standard Page member prefix mm TMainMenupm TPopupMenummi TMainMenuItempmi TPopupMenuItem prefix member lbl TLabeledt TEditmem TMemobtn TButtoncb TCheckBoxrb TRadioBoxlb TListBoxcb TComboBoxscb TScrollBargb TGroupBoxrg TRadioGrouppnl TPanelcl TCommandList7.7 Additional pages bbtn TBitBtnsb TSpeedButtonme TMaskEditsg TStringGriddg TDrawGridimg TImageshp TShapebvl TBevelsbx TScrollBoxclb TCheckListboxspl TSplitterstx TStaticTextcht TChart7.8 Win32 page tbc TTabControlpgc TPageControlil TImageListre TRichEditthr TTrackBarprb TProgressBarud TUpDownhk THotKeyani TAnimatedtp TDateTimePickertv TTreeViewlv TListViewhdr THeaderControl prefix member stb TStatusBartlb TToolBarclb TCoolBar7.9 System p tm TTimerpb TPaintBoxm p TMediaPlayerolec TOleContainerddcc TDDEClientItemddci TDDEClientItemddsc TDDEServerConvddsi TDDEServerItem7.10 Internet page csk TClientSocketssk TServerSocketwbd TWebDispatcherpp TPageProducertp TQueryTableProducerdstp TDataSetTableProducernmdt TNMDayTimenec TNMEchonf TNMFingernftp TNMFtpnhttp TNMHttpnMsg TNMMsgnmsg TNMMSGServnntp TNMNNTPnpop TNMPop3nuup TNMUUProcessorsmtp TNMSMTPnst TNMStrmnsts TNMStrmServntm TNMTimenudp TNMUdppsk TPowerSockngs TNMGeneralServerhtml THtmlurl TNMUrlsml TSimpleMail

7.11 Data Access page prefix member ds TDataSourcetbl TTableqry TQuerysp TStoredProcdb TDataBasessn TSessionbm TBatchMoveusql TUpdateSQL7.12 Data Controls page dbg TDBGriddbn TDBNavigatordbt TDBTextdbe TDBEditdbm TDBMemodbi TDBImagedblb TDBListBoxdbcb TDBComboBoxdbch TDBCheckBoxdbrg TDBRadioGroupdbll TDBLookupListBoxdblc TDBLookupComboBoxdbre TDBRichEditdbcg TDBCtrlGriddbch TDBChart7.13 Decision Cube page dcb TDecisionCubedcq TDecisionQuerydcs TDecisionSourcedcp TDecisionPivotdcg TDecisionGriddcgr TDecisionGraph7.14 QReport page qr TQuickReportqrsd TQRSubDetailqrb TQRBandqrcb TQRChildBandqrg TQRGroupqrl TQRLabel prefix member qrt TQRTextqre TQRExprqrs TQRSysDataqrm TQRMemoqrrt TQRRichTextqrdr TQRDBRichTextqrsh TQRShapeqri TQRImageqrdi TQRDBMImageqrcr TQRComposit EREPORTQRP TQRPREVIEWQRCH TQRCHART 7.15 Dialogs Page dialog unit is a real form packaged by component, so they should follow forms of naming. The type has been defined by the name of the component. The name of its instance is the type instance name that Delphi automatically generated removes the digital suffix.

For example as follows: Example Name Type TOpenDialog OpenDialog TSaveDialog SaveDialog TOpenPictureDialog OpenPictureDialog TSavePictureDialog SavePictureDialog TFontDialog FontDialog TColorDialog ColorDialog TPrintSetupDialog PrintSetupDialog TFindDialog FindDialog TReplaceDialog ReplaceDialog7.16 Win3.1 page dbll TDBLookupListdblc TDBLookupCombots TTabSetol TOutlinetnb TTabbedNoteBooknb TNoteBookhdr THeaderflb TFileListBoxdlb TDirectoryListBoxdcb TDriveComboBoxfcb TFliterComboBox7.17 Samples page gg TGauge prefix member cg TColorGridspb TSpinEditspe TSpinEditdol TDirectoryOutlinecal TCalendaribea TIBEventAlerter7.18 ActiveX page cfx TChartFXvsp TVSSpellf1b TF1Bookvtc TVTChartgrp TGraph7.19 Midas page prv TProvidercds TClientDataSetqcds TQueryClientData SetDCOMCOMCONNECTIONOLEEEEEnterpriseConnectionSck TsocketConnectionRMS TremoteServerMid TMIDASCONNECTY 1, the present document details the program written standard for programming under the Delphi 4 Developer Guide. Under normal circumstances, this document follows the guidelines of the "cancel" format, which is used by Borland International. In the Delphi 4 Developer Guide, the purpose of this document is to illustrate a method. By this method, the development team can maintain a consistent style in the code they have. The purpose of this is to make each programmer in the development group can understand the code of other programmers. This helps to increase the conception and use of code written.

This document does not mean all standards existing in the code. However, its content is enough to help you get a good head. You can add these criteria to meet your needs. We don't agree that you have deviated from these standards used by Borland developers too far. We recommend this because there is a new programmer to join your development team, and their favorite and most familiar is Borland's standard. This document will also be changed as needed in most code standard documents. So you can find the latest update version in www.xapware.com/ddg. This document does not include the user interface standard. This document is independent but equally important. There is already enough third-party books and Microsoft documents including some other guidelines, and we decide not to copy this information, but we will guide you to Microsoft Developers Network and some resources, where you can find what you need. Second, universal source code format rules

2.1 格

The minus finger refers to two spaces at each level. Do not keep TAB characters in the source code, because Tab characters represent different widths with different settings of different users and different resource management tools (print, document, version control, etc.).

You can prevent saving Tab characters from the "Use Tab Character" and "Optimal Fill" check box on the Editor page in the Environment Options dialog box (via Tools | Environment).

2.2 page space

The page space will be set to 80 characters wide. Usually, the source code will not exceed this boundary, but this policy will have some flexibility. Regardless of whether it is possible, those statements that exceed another line will be connected to the previous statements after a comma or other operator. When a statement is interrupted, it should indumb to two characters than the original line statement.

2.3 Begin ... END pairing

The Begin clause should be written in an independent line. For example, the first line below is the wrong way of writing and the second line is correct.

For i: = 0 to 10 do beg file: // error, Begin with for

For i: = 0 to 10 do file: // correct, Begin appears in an independent line

Begin

The exception to this rule is that the appearance of the begin clause is part of an ELSE clause - reference example:

IF some statement then

Begin

...

end

Else Begin

SomeharStatement;

END;

The end statement will always appear in an independent line.

When the Begin statement is not part of an ELSE clause, the corresponding End statement is always indentation to a location corresponding to the Begin section.

Third, Object Pascal

3.1 Brand

Never leave spaces in the middle of the characters between brackets and brackets. The following example demonstrates errors and spaces in parentheses:

CallProc (APARAMETER); File: // Error

CallProc (APARAMETER); file: // correct

Never use unnecessary parentheses in a statement. Brackets should only be used in places they need in the source code. The following example demonstrates errors and correct uses:

IF (i = 42) THEN FILE: / / Error - Excess parentheses

IF (i = 42) or (j = 42) THEN FILE: / / correct - need parentheses

3.2 Reserved words and keywords

Object Pascal reserves the words and keywords are always lowercase.

3.3 Processes and Functions (routines)

3.3.1 Name / Format

The name of the routine will never start with uppercase letters and is distinct to be readable. Below is a process name in incorrect format:

Procedure thisisapoorlyformattedroutinename;

Here is an example of a suitable case routine name: Procedure thisismuchmorereadableRoutinename;

The name of the routine should be consistent with its content. A routine that can lead to a behavior should begin with the verb. E.g:

Procedure formatharddrive;

A routine for setting input parameters should be prefixed as a word set, for example:

Procedure setusername;

A routine used to receive a value should be prefixed as a word GET, for example:

Procedure getusername: String;

3.3.2 Formal parameters

3.3.2.1 Format

If there is, the same type of shape is merged in one statement:

Procedure Foo (Param1, Param2, Param3: Integer; Param4: String);

3.3.2.2 Named

The names of all ginseng should be very in line with the significances they represent, especially in the name of the flag transmitted to the routine. A good parameter name should be prefixed in character A - for example:

Procedure SomeProc (AUSERNAME: STRING; aUSERAGE: Integer);

"A" prefix is ​​set by the presentation that the name of this parameter is corresponding to one of the types of properties or domains in the class type.

3.3.2.3 Sort by parameter

The order of the above-mentioned meticulum focuses on the benefits of the registrant call convention call.

- The most common parameters should be placed first, and other parameters should be arranged in the order from left to right.

- The input parameter list should be placed on the left of the output parameter list.

- Place the general parameters on the left side of the special parameters, for example:

Procedure SomeProc (Aplanet, Acontinent, Acountry, Astate, ACITY)

- Sorting may have some exceptions, such as the process of events. The Sender parameter for TOBJECT is often placed first.

3.3.2.4 Constant parameters

These parameters should be tagged when a parameter is a record type, array type, shortstring, or interface type and when it is not changed in routines. This will make the compiler more efficiently generate code related to these non-changing parameters.

Other non-variable parameters in the routine can also be transmitted. Although there is no effect and improve efficiency, this will provide more information to the user of the modified routine.

3.3.2.5 Conflicts of the name

When two units with the same routine with two names, if you call this routine, the routines in the end of the unit in the Uses clause will be called. In order to solve this "blur" conflict on the USES clause ", you must write the prefix of the associated unit when calling the routine, for example:

SYSUTILE.FINDCLOSE (SR);

or

Windows.FindClose (Handle);

3.4 variables

3.4.1 Names and format of variables

Naming of variables should be consistent with their purpose

The loop control variable should be used as a name, such as I, J, or K, or more meaningful names, such as UserIndex.

The name of the logical variable should be able to fully express the meaning of accurate or false.

3.4.2 Local variables

The local variables in a process should follow the usage and naming conventions of all other variables. Temporary variables should be reasonable.

If necessary, the partial variable should be initialized in one entry routine. The local ANSISTRING variable will automatically initialize an empty string.

Local interface and distribution interface type variable will automatically initialize the NIL, and local variables and OLE variable type variables will automatically initialize to unassigned

3.4.3 Use of global variables

It is not recommended to use global variables. However, it is still necessary to use at some time, and they should only be used when they must be used. At this time, you should work hard to use global variables within a context. For example, a global variable should only be globally located in the IMPLEMNTATION section of a unit. If you intend to use global data in multiple unit classes, you should move them into a common unit and then used by all other units. Global variables can be initialized to a value directly in a VAR clause. Remember, all global data will automatically initialize 0, so do not initialize global variables to a "empty" value such as 0, nil, '', unassigned, and so on. One reason why this is because zero-initialization global data will not occupy any space in the EXE file. Zero - Initialization Data is stored in a virtual data segment, which is assigned in a period of memory after the application is started. Non-zero-initialized global data takes up in the exe file of the hard disk.

3.5 Type

3.5.1 Understanding

If the name of the name is a reserved word, then it should be written. Win32 API types are usually all capitalized and you must follow the agreement of the detailed type name in Windows.PAS or other API units. For other variable names, one letter should be uppercase, and other letters should be missed. Here are some examples:

VAR

MyString: String; File: // Reserved word

WindowHandle: hWnd; File: // Win32 API type

I: integer; file: // Type identifier introduced in the System unit

3.5.1.1 Floating point pointer type

Real types are not recommended because it exists just to compatibility with early Pascal code. In normal cases, use Double to implement the needs of floating point pointers. And, Double is optimized for the processor and bus, and it is also the standard data format defined in the IEEE. Extended is only used when the range is required to exceed the range defined by Double. Extended is the type of Intel definition and does not support in Java. Single is only used when the actual byte size of the floating point pointer variable has its meaning. (, For example, when using another language DLLS).

3.5.1.2 Enumeration Type

The name of the enumeration type needs to be in accordance with the purpose of this type. This type of name needs to be prefixed in character T to indicate that this is a type. The identifier list in the enumeration type must contain two or three characters to correspond to the name of the enumerated type - for example:

TsongType = (Strock, StClassical, StCountry, Stalternative, Stheavymetal, STRB);

The name of an instance of an enumeration type should be the same as the enumeration type of not prefix, unless there is a better reason to give this variable more special name, such as FavoritesongType1, FavoritesongType2, etc.

3.5.1.3 Variables and OLE variable types

Variables and OLE variable types are usually not recommended. However, this type must be used in programs that only have time to know the data type, which appears in COM and database development. OLE variables are used in COM-based programming, such as automation and ActiveX control, and variables are used in non-COM programming, because variables can store local Delphi strings (same as the same string variable) in the same variable, but The OLE variable converts all strings to an OLE string (WideChar string) and does not instance - they will be copied forever.

3.5.2 Structure Type

3.5.2.1 Array Type

The name of the array type needs to meet the purpose of use. The name of this type must be prefeded T. If the array type pointer is required, then the pointer needs to be prefixed and should be immediately declared in front of the array declaration. For example: TYPE

PcycleArray = ^ TcycleArray;

TcycleArray = array [1 € | 100] of integer;

In practical applications, the name of the variable instance of the array should be the name of its type to remove the prefix T.

3.5.2.2 Recording Type

The name of the record type should meet the purpose of using them. The type of statement should be prefixed. If you want to declare the pointer of the record type, it should be prefixed and should close to the previous declaration of the type declaration. E.g:

Type

PEMPLOYEE = ^ Temployee;

Temployee = Record

Employeename: String;

Employeeerate: Double;

END;

3.6 statement

3.6.1 IF statement

The most frequently occurred behavior in the IF / THEN / ELSE statement is placed in the Then clause, while other behaviors that have less likely to be placed in the ELSE clause.

Try to avoid using nested IF statements, using multiple IF statements in this case to judge various possibilities.

Do not use the IF nested more than five depths. The code should be written clearer and clear.

Do not use unnecessary parentheses in the IF statement.

If there are multiple conditions in the IF statement to be tested, these conditions should be arranged from left to right from left to right by less than a few order. Doing so allows the compiler to get the shortcut of Boolerance when compiling code, making your code best optimization. For example, if the condition 1 is fast through condition 2, the condition 2 is faster 3, then the arrangement in the IF statement should be:

IF Condition 1 And Conditions 2 and Conditions 3 THEN

3.6.2 CASE statement

3.6.2.1 General Topics

Each independent unit in a CASE statement should be arranged in a number or alphabetical order.

The action behavior of each CASE unit should be simple and should not exceed four to five lines. If the action you want is too complex, a separate process or function should be used.

The else clause in the CASE statement is only used when the default behavior is required or handled.

3.6.2.2 Format

The CASE statement should follow other structural division and naming conventions.

3.6.3 WHILE statement

In a While statement, it is not recommended to use the EXIT procedure to jump out of the loop, try to use only cyclic conditions to jump out of the loop.

The initialization code used in a While cycle should close to the WHILE cycle, not being separated by other unrelated statements.

Any end process should be carried out immediately after the loop.

3.6.4 for statement

The FOR statement can only replace the While statement when the number of cycles is known.

3.6.5 REPEAT statement

The REPEAT statement is the same as the While statement and follows the same general policy.

3.6.6 With statement

3.6.6.1 General Topics

The WITH statement should save use and have a lot of warnings. Avoid excessive use of the with statement and use multiple objects, records, and more in the WITH statement. E.g:

With record1, record2 do

These things will make programmers feel confused and difficult to find problems.

3.6.6.2 format

The WITH statement follows the format rules for naming conventions and minibo indicated by this document.

3.7 Structure abnormal processing

3.7.1 General Topics

Abnormal processing is used in large quantities of error correction and resource protection. That is to say that once the resource is assigned, a try ... finally must use to ensure that the resource is released correctly. This anomalous protection also refers to the allocation and release of resources in a unit's Initialization / Finalization or an object's constructor / design.

3.7.2 Try ... Finally used

In any case, every assignment should follow a try ... finally. For example, the following code will cause possible errors:

SomeClass1: = TsomeClass.create; someclass2; = tsomeclass.create;

Try

{do some code}

Finally

Someclass1.free;

Someclass2.free;

END;

A more secure and more appropriate allocation process should be:

SomeClass1: = TsomeClass.create;

Try

SomeClass2: = TsomeClass.create;

Try

{do some code}

Finally

Someclass2.free;

END;

Finally

Someclass1.free;

END;

3.7.3 Try ... Except

Only use try ... excepts when they are triggered and you want to perform some tasks. Usually, you don't have to use the Try ... Except statement in order to display an error message simply on the screen, because this will be automatically executed by the Application object. If you want to call the default exception handler after performing some tasks in the Except clause, use Raise to re-trigger an exception to the next handle.

3.7.4 Try ... Except ... Else

The else clause in Try ... Except is not recommended because it interrupts all exceptions including those you are not prepared.

3.8 type type

3.8.1 Names and format

The name of the class type should meet the purpose of using them. Type names should be prefixed to indicate that this is a type of definition - for example:

Type

TCUSTOMER = Class (TOBJECT)

The type of instance is usually the name of the type without prefix T - for example:

VAR

Customer: tcustom;

Note: Check the "Naming Standard of Component Type" to get more information about the component named.

3.8.2 domain

3.8.2.1 Named / Format

The domain name of the class follows the same agreed with the variable identifier, except that they should be prefixed in F, indicating that this is the name of a domain.

3.8.2.2 Visualization

All domains must be private. Want to access the domain outside the class to use attributes.

3.8.3 Method

3.8.3.1 Named / Format

The naming of the method should follow the procedures and functions of this document.

3.8.3.2 Use Static Method

If a static method is used, then this method cannot be inherited by the descendum of the class.

3.8.3.3 Using Virtual / Dynamic Method

If you intend to use the method of this class, you can use the virtual method if you are inherited by the proceedings. A dynamic method is only used when the method has multiple inherits (direct or indirect). For example, a class type contains a can inherit, and 100 descendants should inherit this method, then this method dynamically generates the memory used by 100 descendants.

3.8.3.4 Using Abstract Methods

If you use an abstract method in a class, this class cannot be created. Only use abstract methods in classes that never be created.

3.8.3.5 Property Access Method

All access classes can only appear in the Private or Protaced section of the class. Naming of attribute access methods should follow the process and function's agreed rules. Read Access Method (Method Reader) must be prefixed with a word GET. Writing Access Method (Method Writer) must be prefixed in word Set. Method The name of the parameter of the writer should be Value, and its type should be the type of attribute it operate. E.g:

TsomeClass = Class (TOBJECT)

Private

Fsomefield: integer;

protected

Function GetSomefield: integer;

Procedure setsomefield (value: integer);

public

Property Somefield: integer read getsomefield; ent;

3.8.4 Property

3.8.4.1 Named / Format

The attribute If it is an accessor that is represented as a private domain, then its name should be the name of the domain they operate to remove the explanatory f.

The name of the attribute should be a noun, not a verb. The attribute is indicated by data, and the method is represented by behavior.

The name of the array type should be a plural. In general, the name of the attribute should be singular.

3.8.4.2 Methods Using Access

Although there is no requirement, it is recommended to use a write access method as possible as possible for a private domain attribute.

Four, documents

4.1 Engineering Document

4.1.1 Name

The project document should take a descriptive name. For example, the project name of the Delphi 4 Developer Guide Error Manager is: DDGBUGS.DPR. The name of a program related to system information should be like sysinfo.dpr.

4.2 Form file

4.2.1 Name

Name of a form file should be able to describe the purpose of using the form and suffix FRM. For example, a file name of a "about" form should be AboutFrm.dpr. The file name of the main form should be mainfrm.dpr.

4.3 Data Template File

4.3.1 Name

The name of the data template should be able to represent the purpose of using the data template, and its name should be added two characters of the suffix DM. For example, the file name of the custom data template should be CUSTOMERSDM.DFM.

4.4 remote data template file

4.4.1 Name

The name of the remote data template should be able to represent the purpose of using the remote data template, and its name should be the suffix RDM of three characters. For example, the file name of the custom distal data template should be CustomersRDM.DFM.

4.5 Unit file

4.5.1 Universal Unit Structure

4.5.1.1 Name of Unit

A Unit file should take a descriptive name. For example, the unit containing the application main form should be called mainfrm.pas.

4.5.1.2 Uses clause

The USES clause at the interface section should be included in the unit required in the interface section. Remove those Delphi to automatically join the unit in the program.

The USES clause in the Implementation section should only contain the name of the unit required for the code required in the IMplementation section. Remove unnecessary units.

4.5.1.3 Interface section

The Interface section should contain only those definitions, variables, process / functions of the access types that other units, and the like. Otherwise, it should be placed on the Implementation section.

4.5.1.4 Part IMPLEMENTATION section

The Implementation section should contain those types definitions, variables, procedures / function definitions, etc. that only in this unit.

4.5.1.5 Initialization section

Do not put the time-long code in the Initialization section, which will cause the first interface of the program.

It has a slower.

4.5.1.6 Finalization section

Here you must ensure that you release any resource you assigned to the Initialization section.

4.5.2 Form Unit

4.5.2.1 Name

The unit file of a form should have the same name as the form file it corresponds. For example, the unit name of the "About" form should be AboutFrm.PAS, while the unit name of the main form should be Mainfrm.PAS.

4.5.3 Data Template Unit

4.5.3.1 Name

The unit file of a data template should have the same name as the data template file it corresponds. For example, the name of a custom data template unit should be Customersdm.PAS.

4.5.4 General destination unit

4.5.4.1 Named

The name of the general purpose unit should meet the purpose of using the unit. For example, a utility unit is named bugutilities.pas. A unit containing global variables is named Customerglobals.PAS.

Note that the name of the unit cannot be the same as the name of the unit in all packets used in its work. Not approved with general or universal unit names. 4.5.5 Component Unit

4.5.5.1 Name

The component unit should be placed in a separate catalog to distinguish them in distinguishing between units or components set. They should always be in different directories. The unit name should be consistent with their content.

Note: Check the "User-Defined Component" section to get more information about component naming standards.

4.6 file header

It is recommended to use an information file header in all source files, project files, units, and the like. A good file header should contain the following information:

{

Copyright ... the year, month, day ...

}

V. Forms and data templates

5.1 Form

5.1.1 Form Type Name Standard

The name of the form type should be able to express the purpose of using the form. Type definition should be prefeded T. The prefix followed by the descriptive name. Finally, a Form suffix should be applied to describe the name. For example, the name of the type of "about" the form should be:

TaboutFrom = Class (TFORM);

The definition of the main form is:

TMAINFORM = Class (TFORM);

The name of a user access the form should be like:

TCUSTOMERENTRYFORM = Class (TFORM);

5.1.2 Form instance naming standard

The form instance should be the name of the corresponding class with a prefix T. For example, the name of the example should be: corresponding to the previous form type.

Type Name Example Name

TaboutForm Aboutform

TMAINFORM Mainform

TCustomerentryform Customerentryform

5.1.3 Automatically create a form

Only the main form can be automatically created unless otherwise better reasons do not do so. All other forms must be removed from the automatic creation list in the Engineering Options dialog box. Check out the following sections to get more information.

5.1.4 Mode Form Instantiation Function

All form units should contain a form instantiation function, which is used to create, set, modely display the form, and release the form. This function should return the pattern of the form. The parameters you want to pass should follow the "Parameter Pass" standard specified by this document. The functionality packaged in this way helps the reuse and maintenance of the code.

The variable of the form is to be removed from the unit, and a local definition is performed in a function of the form. Note that this means that the form must be removed from the automatic creation list in the Project / Options dialog. Refer to "Automatically Create Form" later in this document.

For example, the unit below shows a function in the GetUserData form.

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 Data Template

5.2.1 Data Template Naming Standard

The name of the data template should meet the purpose of using the data template. The definition of the type should be prefeded T, followed by the descriptive name, and finally add the debug word "Datamodule". For example, a custom data template is sometimes like:

TCUSTOMERDATAMODULE = Class (TDATAModule)

The name of an ordered data template should be imaged:

TordersDataModule = Class (TDATAModule)

5.2.2 Data Template Instance Name Standard

The name of the data template instance should be the name of the type that does not have a prefix T. For example, for the previous form type, the name of the example should be:

Type Name Example Name

TcustomerDataModule CustomerDataModule

TordersDataModule ORDERSDATAMODULE

Sixth, package

6.1 Comparison of running packages and design packages

The outline of the runtime should only contain the units or components required for other component packages. Additionally, the included attribute / component editor and other code to be designed should be placed in the design timing package. The registration unit should be placed in the design package.

6.2 file naming standard

The name of the package should be followed by:

"Iiilibvv.pkg" - design time package

"Iiistdv.pkg" - running package

Character "III" represents a 3-character identification prefix. This prefix is ​​used to indicate companies, individuals, or other identified entities.

Character "VV" is represented as the version number of the package that you want to correspond to a version of Delphi.

Note that the name of "lib" or "std" in the name of the package is to indicate that this is a design time package or a runtime package.

If it is both a design time package and a runtime package, the name of the file is the same above, for example, the name of the package made for the Delphi 4 Developer Guide should be:

DDGLIB40.PKG - Design Time Package

DDGSTD40.PKG - Running

Seven, component

7.1 User Customizing Components

The name of the component named in the standard component is defined as a class type as the "class type" section definition, and the difference is that they have a 3-character indicator prefix, which can represent companies, individuals, or other entities. For example, the name of the clock member written for the Delphi 4 Developer Guide is defined as:

TDDGCLOCK = Class (Tcomponent)

Note that the three prefix characters are lowercase.

7.2 component unit

The component unit should contain only one primary member, and a major component is a component in the component column. The auxiliary member / object of the main component should be placed in the same unit.

7.3 Using registration unit

The registration process of the component should be removed from the unit itself and put it into a separate unit. This registration unit can be used to register any component, attribute editor, component editor, exemption, etc.

The registration of the component should only be carried out in the design clip, and the registration unit should be included in the design time package and should not be placed in the running moment.

The name of the registration unit recommended is:

xxxreg.pas

The above three prefix characters "XXX" are used to represent a company, a personal or any other entity. For example, the name of the registration unit in the Delphi 4 Developer Guide should be DDGREG.PAS. 7.4 Component instance naming conventions

All components should take a descriptive name. The components of the default name created by Delphi are not abandoned. A lowercase prefix should be designed when the design component type is designed. The reason why the prefix does not use the suffix is ​​when searching, the name of the search component in the Object Check and the Code Explorer is more easily implemented than the type of search member.

7.5 Prefix of the component

The prefix of the following components can be used to design the standard components in Delphi 4. Please join the prefix of a third party component in this list.

7.6 Standard Page

Prefix member

MM TmainMenu

PM TPopupmenu

Mmi TmainMenuItem

PMI TPopupMenuItem

Prefix member

LBL TLABEL

EDT TEDIT

MEM TMEMO

BTN TBUTTON

CB Tcheckbox

RB Tradiobox

LB TListBox

CB TcomboBox

SCB Tscrollbar

GB TGroupBox

RG TradioGroup

PNL TPANEL

CL TcommandList

7.7 Additional Page

BBTN TbitBTN

SB TspeedButton

Me tmaskedit

SG TSTRINGGRID

DG TDRAWGRID

IMG TIMAGE

SHP TSHAPE

BVL TBevel

SBX Tscrollbox

CLB Tchecklistbox

SPL TSPLITTER

StX TSTATICText

CHT TCHART

7.8 Win32 Page

TBC TTABControl

PGC TPAGECONTROL

Il Timagelist

Re TrichEdit

THR TTRACKBAR

PRB TPROGRESSBAR

UD tupdown

HK THOTKEY

Ani tanimate

DTP TDATETIMEPICKER

TV TTREEVIEW

LV TLISTVIEW

HDR THEADERCONTROL

Prefix member

STB TSTATUSBAR

TLB TTOOLBAR

CLB TCOOLBAR

7.9 SYSTEM Page

TM TTIMER

PB TPaintBox

MP TMEDIAPLAYER

OLEC TOLECONTAINER

DDCC TDDECLIENTITEM

DDCI TDDeclientItem

DDSC TDDeServerConv

DDSI TDDeServerItem

7.10 Internet Page

CSK TclientSocket

SSK TSERVERSOCKET

WBD TWEBDISPATCHER

PP TPAGEPRODUCER

TP TQueryTableProducer

DSTP TDataSetTableProducer

NMDT TNMDAYTIME

NEC TNMECHONF TNMFinger

NFTP TNMFTP

NHTTP TNMHTP

NMSG TNMMSG

NMSG TNMMSGServ

NNTP TNMNNTP

NPOP TNMPOP3

Nuup TNMUUUPROCESSOR

SMTP TNMSMTP

NST TNMSTRM

NSTS TNMSTRMSERV

NTM TNMTIME

NUDP TNMUDP

PSK TPOWERSOCK

NGS TNMGENERALRERVER

HTML THTML

URL TNMURL

SML TSIMPLEMAIL

7.11 Data Access Page

Prefix member

DS TDataSource

TBL TTABLE

Qry TQuery

SP TSToredProc

DB TDATABASE

SSN TSession

BM TBATCHMOVE

USQL TUPDATESQL

7.12 Data Controls Page

DBG TDBGRID

DBN TDBNAVIGATOR

DBT TDBText

Dbe Tdbedit

DBM TDBMEMO

DBI TDBIMAGE

DBLB TDBListbox

DBCB TDBCOMBOBOX

DBCH TDBCHECKBOX

DBRG TDBRADIOGROUP

DBLL TDBLOOKUPLISTBOX

DBLC TDBLOOKUPCOMBOX

DBRE TDBRICHEDIT

DBCG TDBCTRLGRID

DBCH TDBCHART

7.13 Decision Cube Page

DCB TDecisioncube

DCQ TDecisionQuery

DCS TDECISISOURCE

DCP TDECISIONPIVOT

DCG TDECISIONGRID

Dcgr TDecisiongraph

7.14 QReport Page

QR TQUickReport

QRSD TQRSUBDetail

QRB TQRBAND

Qrcb TQRCHildband

QRG TQRGROUP

Qrl Tqrlabel

Prefix member

QRT TQRText

QRE TQREXPR

QRS TQrsysdata

QRM TQRMEMO

Qrrt tqrrichtext

QrDR TQRDBRICHText

QRSH TQRSHAPE

QRI TQRIMAGE

QrDi Tqrdbmimage

Qrcr TqrcompositerEport

Qrp tqrpreview

Qrch TQRCHART

7.15 Dialogs Page

The dialog assembly is a real form packaged by the component, so they should follow the form of naming conventions. The type has been defined by the name of the component. The name of its instance is the type instance name that Delphi automatically generated removes the digital suffix. For example, as follows:

Type instance name

TopEndialog OpenDialog

TsaveDialog SavedialogtopenPictureDialog OpenPictureDialog

TsavePictureDialog SavePictureDialog

TFONTDIALOG FONTDIALOGOGOG

TcolorDialog Colordialog

TPrintSetupDialog PrintSetupDialog

TfindDialog FindDialog

TreplaceDialog ReplaceDialog

7.16 Win3.1 Page

DBLL TDBLOOKUPLIST

DBLC TDBLOOKUPCOMBO

TS TTABSET

Ol Toutline

TNB TTABBEDNOTEBOOK

NB TNOTEBOOK

HDR THEADER

FLB TFileListbox

DLB TDIRECTORYLISTBOX

DCB TDRIVECOMBOBOX

FCB TFliterComboBox

7.17 Samples Page

GG TGAUGE

Prefix member

CG Tcolorgrid

SPB TSPINEDIT

SPE TSPINEDIT

DOL TDIRECTORYOUTLINE

Cal Tcalendar

Ibea Tibeventalerter

7.18 ActiveX Page

CFX TCHARTFX

VSP TVSSPELL

F1b TF1BOOK

VTC TVTCHART

GRP TGRAPH

7.19 Midas Page

PRV TPROVIDER

CDS TclientDataSet

QCDS TQueryClientDataSet

DCOM TDCOMCONNECTION

Olee toleEnterpriseConnection

SCK TSOCKETCONNECONNECTION

RMS TREMOTSERVER

Mid TmidasConnection

转载请注明原文地址:https://www.9cbs.com/read-29236.html

New Post(0)