First, preamble
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 // error, Begin with for the same line
For i: = 0 to 10 do // correct, Begin appears in a separate 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); / / Error
CallProc (aparameter); / / 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 / / Error - Excess Brackets
IF (i = 42) or (j = 42) THEN / / 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;
Below 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.
