BCB naming convention [posted documents] Author: snowblue (snowblue)
1. Source program file organization: Each program file unit usually consists of .h files and .cpp files, and puts the public copies of the unit in .h file. The division unit is mainly based on the class. In principle, each larger class should be a separate unit, but there can be a few classes in the case of smaller and multiple small relationships. Only use of more common classes that have been tested in detail). 2. Source program file structure: Each program file should be constructed by the title, content, and additional instructions. (1) Title: The foregoing annotation instructions in the document, the contents mainly include: program name, authors, copyright information, brief description, etc. . (2) Content: For the file source code, the order of the type, the type definition, variable definition, function prototype, and function is implemented (only for .cpp file only). MAIN, WINMAIN, control registration and other functions should be placed in the final portion of the content section, the class defines the order of private, protected, public, __pubished, and try to keep every part of one, according to data, functions, attributes, events order. (3) Additional description: Supplementary instructions at the end of the file, such as reference materials, etc., if the content is not much, it can be placed in the title portion. 3. Edit style: (1) indent: indent in tab, one Tab is four spaces. Pretreatment statements, global data, function prototypes, headings, additional instructions, function description, label, etc. are written. The "{" "}" paired alignment of the statement block, and is aligned with the previous row, the statement of the statement block classes has been suggested for each "{" "}" separately. (2) Space: Data and functions are appropriately spaced between its type, modification (such as __fastcall, etc.) and is aligned. The keyword principle is empty, such as if (...), etc., the operator is equipped with: "::", "->", "[", "]", " ", " "," ~ ","! "," "," - "(pointing)," * "(refer to the use of pointers), etc., there are no spares. (Where is the side of the single operator indexes with the number of individuals), other operators (including most binabar operators and three-metron operators "?:" Both sides are spaced, "(", ")" The operator is empty in its inside, and it can be aligned in the case of the function definition, but can be aligned in the case, but can not be used when the function is implemented. "," The operator is only one after it, it needs to be aligned You can also empty or more spaces, the "SIZEOF" operator is also recommended in its back, whether there is a parentheses, appropriate spaces, and the statement of the comments added to the statement, and the statement is separated and aligned as much as possible. (3) Alignment: In principle, the relationship is closely related to the alignment, including the type, modification, name, parameter and other partial alignment. The length of each line should not exceed too much screen, if necessary, right, go as much as possible, "," or At the operator, it is best to take a head after the line, and the following lines are indented in the first line of the statement, but the statement is still based on the indentation of the first line, that is, the next line is "{" should be with the first line. Align.
(4) Empty line: There is two lines between the various parts of the program file structure. If it is not necessary, it can only be empty, and each function is realized, and the BCB will automatically generate a line "// ----- - "Do separate, and also have a function description annotation for each function, so it usually only needs to empty or not, but at least a row should be navigated for the case where there is no function description. For your own functions, it is recommended to share "// ------". The function internal data and the code should be at least one line, and the code should be spaced in the code. It is recommended to have a variable declaration in the code in the code. At least four "P" in the class, there is also a blank line between the data and the function. (5) Note: The following three points are required to note: A. It must be meaningless; B. The program must be described correctly; C. must be the latest. Note is essential, but it should not be too much. The following is four essential notes: A. Title, additional instructions; B. Function Description: There should be an appropriate instructions for almost every function, usually before the function implementation In the case where there is no function implementation, before the function prototype, its content is mainly the function, purpose, algorithm, etc. of the function, parameter description, return value description, etc., there must be some special hardware and software requirements if necessary. Waiting for the explanation; C. There should be a small amount of explanation in the code inadvertently or inlet, D. and a small amount of other comments. Note There is two kinds of bidders and line bets, which refers to: "/ ** /" and "//" recommendation to a block annotation, D line notes, B, and C depend on the situation, but should be unified, At least Class B annotation in one unit should be unified. 4. Naming Specification: Adhere to the use of Hungarian variable naming practice, type name Press the Borland practice to prefix with "T", the name of the parameter is unified with lowercase "A" prefix, all identifiers will be used in English or English abbreviation, eliminate the use of pinyin, identifier Each word letter is capitalized, abbreviated vocabulary generally all uppercase, only when necessary, "_" interval vocabulary, macro defined with #define is generally written, other specific details.
Third, additional description: This specification history:
August 1996 1.0 Oral Edition November 20, 1997 2.0 Edition on July 1, 1997 3.0 December 16, 2000 3.01 Rev.
Appendix I
Supplementary description of Borland Delphi: Although delphi is not related to casement, it is recommended to program the case in cases, keep the identifier case, for the case of keyword, all lowercase, all uppercase or first letters Overrock, etc., but must remain unified. Delphi supports a variety of multiple block annotations, it is recommended to use "(* ... *)", and the compilation instruction "{$ ...}" and C / C are different.
Appendix 2
Hungarian-Notation: This named method is called a Hungary programmer called Charles Simonyi. Later, he stayed in Microsoft for a few years, so this nomenclature passed Microsoft's various products and documents. The information spread to the world. Now, most of the programmers do no matter what software they use, more or less use this nomenclature. The starting point of this nomenclature is to combine the number of names: the order of the attribute type object description, so that the type of variable and other attributes are visualized when the programmer is variable, and below is the HN variable naming specification, There are also some of themselves: I personally biased:
Attribute part global variable g_ constant C_ C class member variable m_ static variable S_ type part pointer P function FN invalid V handle H long integer L Boolean F floating point type (sometimes finger file) F double word DW string SZ short Type N double precision floating point D count C (usually using CNT) character CH (usually c) integer I (usually n) byte BY word W true R unsigned U
Description Part Max Max Minimum MIN Initialization INIT Temporary Variable T (or TEMP) Source Object SRC Detection Object Dest
Here, the following example: hWnd: h is a type description, indicating the handle, the Wnd is a variable object description, indicating a window, so hwnd represents a window handle; PFNEATAPPLE: PFN is a type description, indicating a pointer to the function, EataPple is a variable object description Therefore, it represents a function pointer variable to the Eatapple function. g_cch: g_ is an attribute description, indicating that global variables, C and CH are count types and character types, and represent variable types, here Ignore object description, so it represents a global variable that counts characters. The above is the general rule of the HN nomenclature.
Appendix three
Other programming style specification (for reference): In the software programming process, if each programmer writes programs in their own habits and style, this kind of program style will reduce the readability of the program, for software The test, communication, reuse, and software maintenance have an extremely adverse effect. In order to solve this problem, this specification must be implemented in order to improve the development efficiency. This specification requires the requirements for programming basic style, readability, structured, correctness and fault tolerance, reusability, etc., which is an integrated manifestation of programming quality. Programmer's programming level = programming specification programming efficiency.
1. Basic Requirements 1.1 Program Structure Chemical, easy to understand, the number of lines of single functions must not exceed 100 lines. 1.2 What is going to do, it is simple, directly when it is straight, and the code is streamlined, and the garbage program is avoided. 1.3 Try to use the standard library function and public functions. 1.4 Do not define global variables at will, try to use local variables. 1.5 Use parentheses to avoid amphibia.
2. Readability requirements 2.1 readability first, efficiency second. 2.2 Hold the comment is exactly the same as the code. 2.3 Each source file has a file header, indicating that the specification is specified. 2.4 Each function has a function head description, indicating that the specification is specified. 2.5 Main variables (structures, joints, class or objects) are defined or referenced, the comments can reflect their meaning. 2.7 Constant Definition (Define) has a corresponding description. 2.8 Each phase of the process has a related note instructions. 2.9 There is a comment before the typical algorithm. 2.10 Using the logical structure of the display program, the indentation volume is consistent, and the Tab is 6 bytes. 2.11 Circulation, the branch level should not exceed five layers. 2.12 Note You can be in the same row with the statement, or you can go up. 2.13 Blank Characters is also a special annotation. 2.14 At a glance, the statement does not comment. 2.15 The scope of the annotation can be: definition, reference, conditional branch, and a piece of code. 2.16 Note (excluding the program head and function header) should account for 1/5 to 1/3 of the total number of lines.
3. Structured Requirements 3.1 No two equivalent branches are prohibited. 3.2 Prohibiting the goto statement. 3.3 Use the IF statement to emphasize only one of the two groups of statements. Do Else Goto and else return. 3.4 Use CASE to implement multiple branches. 3.5 Avoiding multiple exits from cycles. 3.6 The function has only one exit. 3.7 Do not use the condition assignment statement. 3.8 Avoid unnecessary branches. 3.9 Do not use the conditional branch to replace logic expressions. 4. The correctness and fault tolerance requirements 4.1 The program is first correct, followed by beautiful 4.2 Unable to prove that your program has no error, so after writing a program, you should first check. 4.3 Change an error may generate a new error, so the impact on other programs will be considered before modifying. 4.4 All variables must be initialized before calling. 4.5 Enter all user inputs must be checked. 4.6 Do not compare the equal number of floating point numbers, such as: 10.0 * 0.1 == 1.0, not reliable 4.7 Programs and environmental or status relationships, must actively deal with accidents, such as whether the file can be logically locked, whether the printer is online. 4.8 Unit Test is also part of the programming, and the procedure for submitting a joint test must pass through unit testing.
5. Reuse Requirements 5.1 Reusually Complete the relative independent function algorithm or code should be abstract as a common control or class. 5.2 Public controls or categories should consider OO ideas, reduce external contacts, consider independence or encapsulation. 5.3 Public controls or classes should establish a template.
