C language coding specification
1 typesetting rules
1) The program should be written in indented style, each tab is indented using a tab stop (TAB), and the class definitions and methods should be written in the top;
2) The source program is recommended to be written in English, and try not to contain Chinese. Each line does not exceed 80 characters. For long sentences (>80 characters), it is divided into multiple lines. Long expressions are divided into new lines at the lower priority operator. Operators are placed at the beginning of the new line. The new lines are divided appropriately. Into, make the layout neat, the statement is readable; if there are long expressions or statements in the loop, judgment, etc., then the adaptation should be divided;
3) The left brace should be on a separate line and cannot follow the end of the previous line;
4) A variable definition takes one line, and one statement occupies one line;
5) A blank line must be added after the independent block and the variable description;
6) In the case of structural member assignment, etc., the equal sign is aligned, leaving at least one space;
7) If the parameters in the function or process are long, the appropriate division is required.
8) Sorting style of formal parameters:
Ø The most commonly used parameters are placed first;
Ø The input parameter list should be placed to the left of the output parameter list;
Ø Place the general parameters to the left of the special parameters.
2 naming convention
2.1 Application naming
"system abbreviation" + module name
2.2 Naming of submodules
The name of each submodule should consist of words 1-3 that describe the module's functionality. The first letter of each word should be capitalized. Some of the more common abbreviations can be used in these words.
2.3 Naming of variables
The basic principle of naming variables is to make the meaning of variables directly understandable from the name. It can be spelled out with multiple English words, the first letter of each English word should be capitalized, and the English words have abbreviated abbreviations; the prefix of the variable indicates the type of the variable; for the variable whose scope spans more than 10 lines, the name cannot be less. For 4 characters, variables other than I, j, k, etc. must not be used except for loop variables and accumulated variables. Variables are divided into global variables and local variables, and global variables are distinguished by prefixing "g_".
Use meaningful English words, separated by capitalization, the first letter of each word is capitalized
Taking into account habituality and simplicity, local variables that are used conventionally allow very short names, such as n, i as a loop variable, p, q as a pointer, and so on. In addition, it should be noted that global variables should not be defined too much in the program, and local variables can be used in local variables. If you want to use related variables, it is recommended to store them in a class or structure to reduce the number of specific variables.
2.4 Constant naming
All letters of the constant are capitalized. And the words are separated by an underscore "_".
2.5 Function/procedure naming
Function/procedure names should use English names that express function functions. Function names such as function1 and function2 should be prohibited from being used. Words should be separated by capitalization. The global function/procedure name begins with the "g_" prefix.
2.6 Interface naming
The interface name should start with an uppercase letter. If the interface contains multiple words, the first letter of each word is capitalized, and the other letters are lowercase. If the words are abbreviations (such as XML), the first letter is capitalized and the other letters are lowercase (written as Xml).
2.7 class naming
Class names should start with an uppercase letter;
If the class name contains multiple words, the first letter of each word should be capitalized, and other letters should be lowercase; if the words are abbreviations (such as XML), the first letter should be capitalized, and the other letters should be lowercase (written as Xml);
The class name should be a noun or noun phrase;
The naming rules for class member variables are the same as the above rules, but start with "m_" to indicate that they are member variables (Member);
Class names cannot be underlined.
2.8 Method naming
Method names begin with a lowercase letter.
If the method name contains more than one word, the first letter of each word is capitalized except the first word.
Mother lowercase. If these words are abbreviations (such as XML), capitalize the first letter and lowercase the other letters (write Xml).
The method name should be a verb or gerund phrase, meaning "what function is done", "what operation is performed".
2.9 Database naming
2.9.1 Table:
The naming convention of "module name abbreviation + prefix + '_' + table name" is adopted. The name of the table is based on the principle that the contents of the table can be understood.
It can be expressed in Chinese or by English letters representing the meaning of this table; the first letter is capitalized; the prefix represents this table category.
2.9.2 View:
The naming convention of "module name + '_' + view name + 'view'" is usually composed of 8 or less Chinese characters.
2.9.3 Stored Procedure:
Use the naming convention of "Proc+module name + '_' + stored procedure name".
2.9.4 Trigger:
The naming convention of "module name + '' + trigger type + '' + table name" can be superimposed if there are multiple trigger types.
2.9.5 Field:
The naming of the field is based on the principle of understanding the meaning of the field. It is usually spelled out by prefixing multiple English words, and the first letter of the composed field name should be capitalized. Words have abbreviations available. The prefix of the field indicates the data type of the field. For details, see the description of "Data Type". In principle, the naming length of the field does not exceed 18 bytes; the Chinese name of the description field, when designing the database with the database creation tool, needs to be entered.
3 parameter convention
3.1 Input parameter convention
Some functions have input parameters that are input by the function (caller) and used inside the function. In the function business process description followed by the input parameter description area, marked with "input parameters" or "Input Parameters". Add a comment for the parameter after each parameter in the parameter name list.
3.2 Agreement of output parameters
Some functions have output parameters, which are parameters defined by the outside of the function (the caller) that are used inside the function and returned to the caller. In the input parameter description area followed by the output parameter description area, marked with "Output Parameters" or "Output Parameters". Add a comment for the parameter after each parameter in the parameter name list. In addition, the output parameters are generally output as pointers or applications.
3.3 Return value convention
Each function has a return value unless the operation is very simple. For return values ​​with different states, it is recommended to use the return value of long type, 0 is successful. For error class return values, modules at the same level are represented by a Unicode. In the output parameter description area followed by the return value description area, marked with "return value" or "Return values". The return value indicates the various types of return values ​​and their meanings.
4 annotation convention
In the software for each file header, custom functions and variables, important processing must have the necessary comments.
4.1 Source program header comments and specifications
Each source program (including stored procedures) must have three parts: a header description, a release description, and a function structure:
Source header description
FileName:
Copy Right:
System:
Module:
Function:
See also:
Author:
Create Date: The external name of the program (such as *.prg, *.cpp)
Xxx company copyright version information
The name of the system or project where this document is located
The name of the function module where this file is located
Briefly explain the function of this program
Related detailed design document number
Coding staff
Creation date
Source version description
Editor:
Version:
Edit Date: Modifying people
version number
Modified date
4.2 Comments and specifications of the function header
Name:
Function:
Input:
Output:
Return:
Syntax:
Env:
Calling: function name
Briefly describe the function of a function or process
[Parameter 1] - [Description...]
[Parameter 2] - [Description...]
[Parameter 1] - [Description...]
[Parameter 2] - [Description...]
[return code 1] - [description...]
[return code 2] - [description...]
Call syntax (optional)
Environmental requirements and impact (optional)
The function being called (optional)
4.3 Variable Comments
Indicate the purpose and value convention of the variable directly after the variable, for example:
4.4 Type Definition Comments
Refers to comments defined by classes and records. Indicate the purpose of the definition in the comment.
Section 4.5 notes
The member methods of the same class are required to be arranged together, and the functions and process requirements that work together to achieve the same function are aligned. Code usually uses several functions and procedures to implement a function. In this case, you need to use the area comments to mark these functions and procedures with common purpose.
Use the entire line of "*" as an isolated line to make the program clear and readable.
Generally deleted code is not recommended to delete directly, it is best to comment with "/ /".
4.6 Notes in the code
Where the comments are required in the code are:
Ø The key part of the code;
Ø Use special algorithms or more logical code;
Ø In the modification or deletion of the code part, you need to add comments; modify / delete people, purpose.
5 The scope of the variable
Try to narrow down the scope of the variable. For variables that are pointers, the following conventions should be followed:
Ø Locally allocated space is released locally.
Ø The function body cannot allocate space and return the space pointer as a function parameter.
Ø The dynamic global space must be released at the end of the program.
Ø All dynamically allocated space is released at the corresponding level of the module, and is released immediately after use. Non-repeating release phase
The same pointer.
6 function / process definition
A comment on the functional description of this function should be added at the definition of the function. Describe the function in one sentence. Available in English or Chinese. The functional comment format requires all code to be consistent.
7 Function Business Process Definition
After the function description, add the main business process comments for the function. You can use multiple lines to describe the business process. Available in English or Chinese. The business process annotation format requires that all code be consistent.
Business process comments can be as detailed as possible, and the length of the comments can be as long as the code length, but not too long.
For example, the business process for processing N-order functions is defined as follows:
Hoodie Jacket,Beige Hoodie,Hooded Shirts And Tops,Hoodies For Women
GUANGZHOU LIWEI ELECTRONICS CO.,LTD , https://www.gdliwei.com