Delphi coding specifications Author: Tulipsys Update date: December 16, 2003 Contents 1. General conventions (naming - indentation and spaces - margins - case - comments) 2. Statement (begin...end statement-if statement-case statement-for statement-while statement-repeat statement-with statement-exception handling statement) 3. Procedures and functions (naming and format-formal parameters-variables-type-custom types) 4. The purpose of formulating coding standards related to object-oriented (class naming and format-field-method-property-method implementation) is to enable a group of programmers to generate code in the same style, so that a team can form and maintain a certain style. If this goal is achieved, the entire project's files will look like they were written by a programmer. Goodness is fun, but the advantage is that each programmer's code is easy to understand by others, which will greatly improve the maintainability of the code and therefore reduce maintenance costs. This is an ideal situation for any team. For individuals, choosing or self-generating a coding norm and adhering to this norm can also produce good results. This is a very tempting goal by the way, but not too difficult to achieve. Each programming language has its own coding standards. Coding standards can be said to be a summary of experience. Of course, we must also learn from the standards of other programming languages. Therefore, it is very important to learn from others. Secondly, the use of coding standards is to simplify the work of programmers. The meaning of "simplification" is not to reduce the amount of code (on the contrary, many times following the standards will bring more code), but to reduce the programmer's labor in maintaining the code. quantity. Programming is a very complex job. It is daunting to deal with various relationships, and there are inextricably linked between various relationships. Programmers should spend most of their energy dealing with relationships and avoid wasting time on too detailed issues. If he can understand the idea and structure of the program at a glance, a maintenance plan will be formed quickly. Moreover, the coding standard should be a very user-friendly standard that you can refer to and modify, but it must be easy to use. But in a group, make sure everyone uses the same standards. Programming is a very flexible job. Only with flexible thinking and flexible application can good results be obtained. In addition, the use of specifications is largely to reduce the memory burden on programmers. Human thinking ability is extremely excellent, but memory is very poor. We face computers all day long, and the most important thing it wants to help us do is memory. Therefore, it is one of our goals to maximize the thinking advantages of programmers. Finally, programming tools have a great influence on coding standards, and this influence comes from the developer's programming style. Also based on C++, we will not use exactly the same coding specifications in Microsoft Visual C++ and Borland C++ Builder. Microsoft and Borland have different and very distinct styles. As users, we can make changes based on this, but there are limits. In fact, when we make choices about vendors and development tools, we also determine our future style. 1. General conventions 1.1 Naming The basic principle of naming is that the name should clearly express the function of the data. Object Pascal supports long file names. Names should use verbs, nouns, or a combination of both. You must not use reserved words and keywords defined in Delphi, and try not to use reserved words and keywords defined in other languages. Try to use complete words and avoid abbreviations, prefixes and suffixes, underscores or other symbols. Hungarian nomenclature is not recommended. Naming conventions are used to ensure readability of names. Naming standards represented by Hungarian nomenclature have developed many prefixes and suffixes to indicate the type, scope, or other various attributes of data. In Delphi, you can certainly use this method, but this is not a recommended method. One reason is that this type of naming convention brings too many additional memory tasks, and another reason is determined by the characteristics of Delphi itself. Delphi's mandatory type checking will automatically monitor the usage of all variables, so we only need to pay a little attention (pay attention to the capitalization of words) without having to laboriously add various prefixes. In addition, consideration of data should be based on meaning rather than type or scope, and attention should be placed on program structure, logical relationships, and design ideas. So in Delphi you only need to use a complete combination of words to name, don't consider anything else, and of course you should keep it as concise as possible. In some statements (such as for loops) we need to use several integers as counting variables. Here you can simply use the three letters i, j, and k as variable names. This is a habit that was developed and retained in the Fortran language, and it has proven to be very useful and easy to understand. Of course, we would have better results using a more meaningful name, such as: MyCounter. Generally speaking, the three letters i, j, and k are completely sufficient, otherwise more processes or functions should be divided. Here are a few examples: 1. SongsList //Indicates that this is a list of songs. Song uses the plural to indicate that there is more than one song. 2. SetCarColor //Indicates that this is a function to set the color of the car. If a TCar class is defined, then SetColor is used in the class as a function member to set the color of the car. Also pay attention to the naming of Boolean variables. The name of a Boolean variable should clearly indicate the meaning of True and False. For example, for a variable that records whether a file exists, using IsFileExisted is better than using FileExisted. Finally, never name a global variable Temp or Tmp, but it is still allowed within a procedure or function. In fact, there is a bit of controversy about this rule. Some coding standards are more strict. Such naming is absolutely prohibited, even in procedures or functions. However, many times this naming is really convenient, especially for procedures or functions. If it is used as a global variable, there is likely to be an assignment statement with mismatched types. Although the compiler will give you a lot of help at this time, it is difficult to avoid the occurrence of small errors. In summary, following this rule will produce better results, but nothing should be strictly adhered to if necessary. 1.2 Indentation and Spaces Two spaces should be indented between each level. This will make the program clear and well-organized. Never use tab characters, because the width of tab characters is difficult to maintain consistent with different settings and applications, but don't expect your program to be viewed only in Delphi. Also pay attention to the use of the editor. If you only choose Delphi, there is no problem; if you also use a text processor such as Word, please pay attention to using appropriate fonts to ensure that the width of each letter and symbol is the same. . When printing with a text processor such as Word, you should also pay attention to the selection of fonts. The use of spaces is also to keep the program clean and allow programmers to quickly understand the program structure. The following are some specifications and corresponding examples: 1. There should be a space between each word. For example: for TMyClass = class(TObject)2． There should be a space around "=", "<>", ">=", and "<="; there should be a space to the right of ":=" and ":", but not to the left. For example: if a = b then a:= b; a: integer; 3. There should be a space between reserved words and keywords and the symbol on the left, but not between the symbol on the right. For example: PRocedure ShowMessage; overload;4. Use of brackets: In the definition and call of procedures and functions, no spaces should be left between brackets and external words and symbols; no spaces should be left between brackets and internal words. In the conditional judgment of the if statement, spaces should be used between reserved words such as and and or. For example: function Exchange(a: integer; b: integer); if (a = b) and ((a = c) or (a = d)) then … end;1.3 margin Delphi editor is about 81st from the right There is a dark line left at the character. In fact, under Delphi's default interface, when the resolution is 800*600, the maximized window will be displayed 4 letters to the left of the dark line. Therefore, do not write source code outside the dark line, which means that each line should not exceed 80 characters including leading and middle spaces. If the statement is too long, then the line break is completed, and the line break must be indented by two characters. This is also easy to print, and the parts beyond the dark line will not be printed in Delphi. If you use word processing software such as Word to print a Delphi program, the excess part will be moved to the beginning of the next line, making the printed program difficult to read. Therefore, try to make all adjustments while writing code, and do not leave this kind of work to printing. When wrapping lines, pay attention to maintaining the readability of the program and try to keep the complete part. As an example, if the function is too long, wrap a complete parameter description instead of just the data type declaration. The first two ways of writing below are correct, and the following ways of writing are wrong: function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //Correct function AdditonFiveInputNumber(a: integer;b: integer;c: integer;d: ineger;e: integer): integer; //Correct function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger; e: integer): integer; //Error function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer ): integer; //Error function AdditonFiveInputNumber(a: integer; b: integer; c: integer; d: ineger;e: integer): integer; //Error 1.4 The first letter of each word in the custom name must be uppercase and lowercase, and other letters must be lowercase. Delphi reserved words and keywords should all be lowercase. The writing method of Delphi predefined functions is the same as the writing method of custom names. Basic data types in Delphi should be lowercase, and the first two letters of extended class types should be capitalized (the first letter of a class type is "T"). Here are some examples: 1. Custom name: MyFavouriteSong, CarList; 2. Reserved words: if (a = b) and ((a = c) or (a = d)) then … end; 3. Delphi predefined functions :ShowMessage('Everything all right');4. Delphi extension class type: MyStrings = TStrings.Create;1.5 Comments Delphi supports two types of comments: block comments ({}) and single-line comments (//). The purpose of comments is to explain the design ideas of the program and help programmers understand the ideas of the program written two years ago or even yesterday as soon as possible. This is actually to solve the memory problem. The brain should not be overused as a memory. Never rely too much on the brain in programming, but use words as much as possible. Therefore, comments are a very important aspect in programming languages, although many people (especially beginners, including a considerable number of programmers) don't mind this and they rarely write comments. Another application of comments is in the program debugging stage. For example, if there are two statements and you don't know which one is better in advance, you need to test: put "//" before a statement (that is, change the statement to comment), run another statement, and then do the opposite, we can easily make the choice. If it is a group of statements, use block comments, but be sure to place "{" and "}" in conspicuous positions, such as on separate upper and lower lines. The following are some usage principles: 1. In most cases, it is necessary to place comments in front of custom variables and types. 2． In most cases, it is necessary to place a comment at the top of the unit file. Here, the comment should include: file name, creation date, modification date, author, modification author, and necessary description. 3. Comments should be meaningful, do not use useless comments. For example: while i < 8 dobegin … i:= i + 1; //Add one to iend; the comment "//Add one to i" is meaningless here, of course it does not mean a simple statement (similar to: i : = i + 1) no comment is needed. Because simple statements often play a very important role, if this statement makes people question or is difficult to understand, then the function of this statement should be marked. 4. Don't try to create monograms in comments unless you think it's absolutely necessary. Because it is very difficult to modify the annotation while keeping the pattern intact and beautiful. . 5. To distinguish temporary comments from permanent comments, you can use your method to place special symbols in the comments. The advantage of this is that it is easy to find. 6. Changes to statements are mapped to corresponding comments. 7. There should be a clear gap between comments and code, so that you can tell at a glance which is a statement and which is a comment. You can place comments on the line before or after the code line, or leave at least two spaces immediately after the code, but do not put the code after the comment when the code and the comment are on the same line. In addition, do not put the code after the comment. Comments are placed in the middle of the code.