[C/C ++/Embedded] style specifications for Embedded C Programming

Style specifications for Embedded C Programming

I. Overview
This document describes the programming style that should be paid attention to in C language programming in embedded development,
Programs compiled by different personnel have similar styles, laying the foundation for convenient maintenance of programs.
Target personnel: All developers involved in C programming.

Ii. file organization and structure
 1.1 file organization
Generally, the system module is determined during the design, and the interface part of each module is determined.
We use two files:. h and. C.
. H is the Module Interface part and can only be placed:
1) function declaration published by this module;
2) global variable Declaration published by this module;
3) data structure definitions exposed by this module (struct that may be used by other modules );
4) macro definitions exposed in this module; macros that may be referenced in other modules, such as channle_maxcount;
5) All other local module variables of this module. Internal functions of this module cannot be declared in. h;

. C is the implementation part of the module and can be freely defined:
1) module variables required by this module;
2) partial module functions for use only in this module; if you think it can be used as a necessary function library, you can separate
Write a module to make it a public function library;
3) Declare the implementation part of the function in. h;
 1.2 file structure
Each. c file consists of the following parts:
1) Copyright description, file description; format:
/*
* Comm. c This module implements the serial communication, include
* Above layer's Bussiness
*
* Version: @ (#) Comm. c 1.0.1.1 2005-3-19
*
* Authors: Synchronized Pang, <shenglipang@163.com>
*
* Fixes:
* Synchronized Pang: refix it. 2005-4-6
* Wangjianfeng: Fill the file. 2005-4-6
* Export Pang: Create the file but not fill it. 2005-03-19.
*/

2) include part
// Includes...
//-----------
# Include <stdio. h>
# Include <stdlib. h>
# Include <string. h>

# Include "com. H"
# Include "MCU. H"

First, it contains the standard library header file, which is included in angle brackets <>;
Empty line and then write the header file of this project, with double quotation marks containing "";

3) const Section
Define the constants and macros required in this file. The format is as follows:
// Consts...
//---------
Const int phone_maxcount = 128;

# Define read_1302 (REG) * (unsigned char xdata *) 0x8000 + REG)

Note: constant definitions can be defined before use. If possible, they can be placed here.
Defined before use.

4) data structure definition section
Define the data structure used by this module, for example:
Typedef struct hub_macframe
{
Uchar channelid;
Union {
Uint beginpos1;
Uchar memindex1;
} 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 data structures (struct) to organize closely related data, rather
Scattered variables represent things. Often, a thing can use a struct to represent all its attributes.

5) module variable definition
After defining the data structure, you can define the global variables required in this module. For example:
// Global values...
//----------------
Objectpool data hub_framepool;

5) module private Function Definition
This part defines only the functions called by this module, which is called the module private function.

6) module interface function implementation
This section defines the interface functions declared in (Implementation). h.

Iii. identifier
Identifiers are user-defined object names, variable names, constant names, function names, array names, subroutine names, type names, etc.
Name.
We agree on the following points:
1) The variable name, function name, array name, and subroutine name should all be named in lowercase letters; the constant name should be named in uppercase letters as far as possible;
2) Select a name. After the module is determined, its internal function name, subroutine name, and module (global) variable name are
Module name_identifier. Such as com_send_message, com_receive_data, and com_entity.
Naming of local variables in functions in a module is not required.
3) The identifier should be able to correctly express its meaning and prevent the use of I, j, and other names without any meaning in global variables.
4) The identifier does not have to be too long. If it is too short to express clearly, you can extend it appropriately and use underscores to separate words, such:
Com_send_message, phone_query_channel_state (char chnid), etc.

 
Iv. Notes
You can write comments as needed, but the Module Interface must have comments.
Annotations are generally prior to or in parallel to the commented object.
// And/**/are not required.

 
V. Visual Organization
5.1 code lines
The rules are as follows:
1) one line of code only does one thing, such as defining only one variable or writing only one statement. This code is easy
It is easy to write comments.
2) if, for, while, do and other statements occupy one row, the execution statement must not be followed by it. Regardless of the statement
Add {} (even if there is only one row ). This prevents writing errors.
 5.2 Spaces
The rules are as follows:
1) Leave a space after the keyword. Keywords such as const, virtual, inline, and case should be left at least
A space. Otherwise, the keyword cannot be analyzed. After keywords such as if, for, and while, leave a space before
'(' To highlight keywords.
2) do not leave spaces after the function name, followed by the left brace '(', which is different from the keyword.
3) '('backward followed,') ','; 'follow forward with no space left.
4) ',' and then leave a space, such as function (x, y, z ). If ';' is not the end symbol of a row
Leave spaces, such as for (initialization; condition; update ).
5) value assignment operators, comparison operators, Arithmetic Operators, logical operators, bitfield operators, such as "=", "+ ="
">="," <= "," + "," * "," % "," & "," | "," <", Before and after binary operators such as "^", add
Space.
6) The unary operator is like "! ","~ "," ++ "," -- "," & "(Address operator) and so on without spaces.
7) operators like "[]", ".", and "->" do not add spaces before and after them.
8) for long for and if statements with expressions, some spaces can be removed for compact purposes,
For example, for (I = 0; I <10; I ++) And if (A <= B) & (c <= D )).
 5.3 blank lines
Empty rows separate program paragraphs. The program layout will be clearer if there are few blank lines.
Empty rows do not waste memory. Although printing programs containing empty rows will consume more paper, it is worth it. So no
Do not want to use empty lines.
The rules are as follows:
1) Add blank lines after each class and struct declaration and after each function definition.
For example, empty rows between functions.
// Empty rows
Void function1 (...)
{
...
}
// Empty rows
Void function2 (...)
{
...
}
// Empty rows
Void function3 (...)
{
...
}
2) in a function, logically close-related statements do not add blank lines. Separate empty lines elsewhere.
For example, empty rows in a function.
// Empty rows
While (condition)
{
Statement1;
// Empty rows
If (condition)
{
Statement2;
}
Else
{
Statement3;
}
// Empty rows
Statement4;
}
 5.4 indent
The rules are as follows:
1) The program's delimiters '{' and '}' should have an exclusive row in the same column and be left aligned with the statements that reference them.
2) The code block in {} is left aligned at the right digit. We need to use the tab key for alignment. One tab key is four.
Space width.
Nested {} is aligned with indentation, for example:
{
...
{
...
}
...
}

-------------------------------------------------------------
| Modifier | modification time | version | Modification Item |
-------------------------------------------------------------
| Victorpang | 2005-4-6 | v1.0.1.1 | create and write |
-------------------------------------------------------------