The purpose of writing this standard is to unify the writing format of component code so that all Delphi programmers ---- Whether it is a beginner or senior developer - can easily maintain and understand them. For some components that are not fully compliant, it is very excellent and has been added to the source code knowledge base, we will give certain flexibility when reviewing. However, any programmer should come with the correct head and instruction documentation when submitting their code, and fill in, this is extremely important. This work will make your code easier by the source code knowledge base.
In principle, we will follow the specification used in the Delphi Code Style Guidance of Mr. Calie Calvert in the Borland Techvoyage site.
5.1 Component code must contain information
5.1.1 Head (Author's Name / etc., version control information)
Any of the top part of the source code file submitted to the knowledge base must be attached to the header format shown in Figure 1, which is valid for Borland Delphi and Borland C Builder.
{------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- NOT USE This File Except in ComplianceWith The license. You may ketain a copy of the license athttp://www.mozilla.org/mpl/mpl/
Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either expressed or implied. See the License for the specific language governing rights and limitations under the License.
The Original Code is: xxx.pas, Released 2000-06-15.
The Initial Developer of the Original Code is Joe Doe
Contributor (s): ____________________________________.
Last Modified: 2000-mm-dd; Current Version: X.xx
You May Retrieve The Latest Version of this file at the project jedi home page, located at http://www.delphi-jedi.org
KNOWN ISSUES: ----------------------------------- ------------------------------}
Figure 1 Standard component head
The "XXX.PAS" in the "The Original Code" stands for the source file name. Usually, the source file name is different from the component name you develop. For example, a component called TJVScreen should Contains a file called Screen.Pas. As a convention, the source file (.PAS) should not contain "TJV" or "JV" prefix. The "Initial Developer" column should include the original author full name, and email address. It is important to leave a mail address for your convenience of comprehension and other connections.
5.1.2 Mozilla License Agreement Abandon Statement
The original author only allows the standard header adopted in 5.1.1. If there is no special statement to abandon the protocol, the source file will not be adopted.
There is a case where the code is placed in the public domain, in which case, replace the Mozilla license agreement with the following statement.
{------------------------------------- ---------------------------- this is an original work by Joe Doe and is hereby placed in the public domain.
The Original Code is: xxx.pas, Released 2000-06-15.
The Initial Developer of The Original Code Is Joe Doe
Contributor (s): ____________________________________.
Last Modified: 2000-06-15 Current Version: X.xx
You May Retrieve The Latest Version of this file at the project jedi home page, located at http://www.delphi-jedi.org
KNOWN ISSUES: ----------------------------------- ------------------------------}
5.1.3 Process / Function Block
The original author also needs to add a detailed description of each process or function. The text must be properly indented:
{------------------------------------- ----------------------------- Procedure: Tjvscreen.DemoEventHandler Description: Author: Joe Doe Date Created: 3/1 / 1996Date Modified: MM / DD / YYYYY by Joe Foo Purpose: KNown Issues: ------------------------------------- -----------------------------------------}
Procedure tjvscreen.demoeventhandler (Sender: Tobject; Col: longint; row: longint; rect: TRECT; State: TgridDrawState); // Refer to notes
Var i, J, Thisnum, Thatnum: Integer; isalive, ISPURPERPLE: BOOLEAN
Begin (? End)
Figure 2 - Standard function / process block
5.1.4 Usage of the prefix in the source code
The following is the prefix coding method we recommend:
Component prefix (example: tjvhtmlhelp) Requires member prefix (for example: fdefaultWindow)
Class prefix (Example: TJVHTMLHELPROUTER) Requirements
Global Variable Prefix (Example: GHTMLHELPROUTER) Requirements
Pointer prefix (Example: PMYPOINTER) Requirements
Pointer Variable Prefix (Example: Popupdefsptr) Requirements
Enumeration Type Prefix (Example: Albottom) Requirements
Other prefixes do not require
5.1.5 assertion
Insert an assertion in the source code (some shortest pretreatment and post-processing of the process / function) is a coding method worth advocating. This will help end users understand the intent of the author of the component. As an assertion is only used in the Delphi's integrated environment, without compiling in the final version, there is no need to use any concerns.
5.2 Component Name
All JEDI-VCL components use standard "TJV" prefixes to distinguish between other components (please pay attention to "J"). TJV has been registered in the Delphi prefix registry of Developers.href.com, belonging to Project Jedi.
5.3 Source code library management personnel to modify the permissions of component names
Some submission components are either homologous to the other component of the game, either name or prefix is inappropriate. For example, a function is to name TJVPrint to output characters on the screen, because print It is easy to think about the printer. Based on the above consideration, the source code library management has a responsibility to modify the name of certain components to make the component naming clearer or to ensure the uniqueness of naming.
5.3.1 Modify the name after the component is released
Once the component is selected and added to the source code library, its name should be fixed. Allow modification names may have unnecessary trouble, especially for users who are using old names without timely update.
5.4 Source code format
The code format of Borland Delphi must be consistent with the current Borland's encoding standard defined by the Delphi VCL. As mentioned earlier, in principle, we will follow the specifications of Mr. Callie Calvert in Delphi Coded Style Guidance. The purpose of this is to provide a unified format they can identify to all Borland Delphi developers. It is what we have to avoid from the basic specification.
Note in 5.5 code
It is best not to exceed one line for method functions. The comment is used to explain the code, not tell others how to use it. In a method, try to add a comment only after you need to explain. Not like this.
Form.show // show form
As a reference, try to keep the ratio of each ten lines corresponding to a row of comments.
5.6 other
· Space: After the comma and colon, add space, operator ( , -, *, /,: =, =, <,>, etc.) should have spaces.
• There are no multiple commands or variable declarations that are not allowed in the same line.
· For methods without comments, at least the division line (such as: // ----- 80 characters wide) will be separated from each other. For each method, it is usually not required, for example, a method called counTERRORS does not need to comment.
· For complex logic or mathematical expressions, try to use parentheses to increase readability, although not necessarily need from the perspective of syntax.
• In logical expressions and other parts that are prone to trace debugging should maximize the use of functions.
· Explicitly revocation calls (such as My DynamicArray ^ [0]) no longer need, and should be avoided at any time.
• The execution of the structured function makes the function only at a point (End key) instead of being aborted by Exit (possible).
