Embedded C programming style specification
1. Overview This document describes the programming style that should be paid attention to in embedded development, and the program that makes different modules, and the procedures written by different people have a similar style, which is easy to maintain the basis for the program. Target: All developers participating in C programming.
Second, document organization and structure 1.1 file organizations generally determine the system module when designing, and focusing on determining the interface part of each module, each module we use two files: .h and .c. .H is the interface portion of the module, only allowed to place: 1) The function declaration of this module disclosure; 2) Global variable declarations disclosed in this module; 3) The data structure definition of this module (ie other modules may be used ); 4) Macro definitions disclosed in this module; macros that may be referenced in other modules, such as CHANNLE_MAXCOUNT; 5) Other partial module variables of all of this module, the internal function of the module is not allowed to be declared in .c is The module implementation section, can be freely defined: 1) The module variable required for this module; 2) Only the local module function used only for this module; if you think it can be used as a necessary library, you can write a module separately to make it public Function library; 3). The implementation of the function of the function; 1.2 file structure Each .C file is divided into several parts: 1) Copyright description, file instructions; format is as follows: / * * Comm.c this module Implements The Serial Communication, Include * Above Layer 'S Bussiness * * Version: @ (#) Comm. C 1.0.1.1 2005-3-19 * * Authors: Victorpang,
4) Data Structure Definition Part Defines the data structure used in this module, such as: type {uchar channel hub_macframe {uinter channel; uion {uint beginpos1; undhar minutesEx1;} u1; union {uint endpos1; uint length1;} u2; // frame header uchar sourceadd; uchar destadd; uchar headchk; uchar chkcorrect; struct hub_macframe xdata * next; // use to indicate it's parent, when insert into send list, // if insert method is copy, we increase frame's ref, and set new // frame's parent to its parent struct hub_macframe xdata * parent; #define beginpos u1.beginpos1 #define memindex u1.memindex1 #define endpos u2.endpos1 #define length u2.length1} hub_macframe; Note: we advocate the use of organizational relational data structure (struct) close Various data, do not advocate the use of scattered variables to indicate things; often one thing can use a Struct to represent all of his properties. 5) The module variable definition section After defining the data structure, the global variables required in the module can be defined in this section. Such as: // Global Values ... // --------------- ObjectPool Data Hub_FramePool; 5) Module Private Function Define Some This section defines the function called only this module call, called Module private function. 6) Module interface function Implement part of the interface function declared in this part definition (implementation).
Third, the identifier identifier is a general name for user-defined names such as file name, variable name, constant name, function name, array name, subroutine name, and type name. We agree to the following: 1) Variable name, function name, array name, subroutine name, named lowercase letters; constant names are named by uppercase letters; 2) Selection of names. The module determines that its internal function name, subroutine name, module (global) variable is the module name _ identifier. Such as com_send_message, com_receive_data, com_entity, etc. Naming of local variables in modules, do not make requirements. 3) The identifier should be able to correctly express its meaning, eliminate the names of I, J and other meanings in global variables. 4) The identifier does not have to be too long. If it is too short to express, it can be extended appropriately, and each word can be divided using the next line, such as: com_send_message, phone_query_channel_state (char chnid).
Fourth, the annotation can be annotated as the situation, but the interface part of the module must be annotated. Note Generally, in front or parallel part of the commented object. Use // and / * * / do not request.
5. Visual Organization 5.1 The code line rules are as follows: 1) One line of code only does one thing, such as only one variable, or write only one statement. This code is easy to read and is convenient to write a comment. 2) IF, for, while, do, other words, executing statements must not follow. No matter how much is the execution statement, add {} (even if there is only one line.). This prevents writing errors. 5.2 The space rules are as follows: 1) Keep spaces after the keyword. At least one space is left after const, virtual, inline, case, etc., otherwise the keyword cannot be analyzed. You should leave a space with the left bracket '(' to highlight keywords after keywords, etc., and to highlight the keyword. 3) '(' Tightening, ')', ',', ';' The front is tight, keeping the space at the space. 4) ', then leave spaces, such as Function (X, Y, Z). If ';' is not the end symbol, then leave the space, such as for (Initialization; Condition; Update). 5) Assigning operators, compare operators, arithmetic operators, logical operators, bit domain operators, such as "=", " ="> = "," <= "," "," * ", "%", "&&", "||", "<<", "^" should add spaces before and after the binary operator. 6) One dollar operator is not adding space before and after "!", "~", " ", "", "&" (address operator). 7) Imponsions "[]", ".", "->" do not add spaces before and after. 8) For the FOR statement and the IF statement for expressions, some spaces can be removed for compact, such as for (i = 0; i <10; i ) and IF ((a <= b) && (c < = D)). 5.3 Dark cross-rows play the role of separating the program. Dedicated (more but less) will make the procedure layout clearer. The blank line does not waste memory, although printing the programs containing a blank line will consume more paper, but it is worth it. So don't bear to use blank lines. The rules are as follows: 1) After each class, the structural declaration, each function defines the end after the end of the function. Such as: empty line between functions. // Dark Void Function1 (...) {...} // 空 行 Void function2 (...) {...} // 空 行 Void function3 (...) {...} 2) In a function body, logically closely related statements Do not vacuum line, else should be separated elsewhere. Such as: the interior of the function.
// Dark While (condition) {statement1; //}}}}} else {statement3;} //}} 5.4 The indentation rules are as follows: 1) Division '{' {'{' And '}' should be exclusively and in the same column, and is aligned with the statement that references them. 2) The code block within {} is aligned in the right side of '{' right. We specify that the Tab key is used, and a Tab key is 4 space widths. Nested {}, use indential alignment, such as: {... {...} ...} --------------------------- -------------------------------- | Modify | Modify Time | Version | Modify Item | ------ -------------------------------------------------- ----- | Victorpang | 2005-4-6 | V1.0.1.1 | Created, Written | -------------------------- -----------------------------------
