Modular suggestions for C language in large projects

A large software project usually contains many complex functions. Implementing this project is not a single programmer, but usually requires an effective division of labor and cooperation from a team, in a complete project that focuses on C code, you often need to add code in other languages, such as the mixed use of C code and assembly code, C files and C ++ are used at the same time. These increase the complexity of a software project. To improve the software quality, it is very important to organize various codes and files reasonably. The purpose of organizing code and documents is to make the team work more effectively, so that the software project has good scalability, maintainability, portability, reduction and testability, and prevent errors, improve software stability.

Software projects usually adopt hierarchical development and modular development. For example, an embedded software project may have a driver layer, an operating system layer, a function layer, and an application layer, each layer uses the interfaces provided by its lower layer and provides call interfaces for its upper layer. A module is a unit that completes a function in each layer, for example, the driver of each device in the driver layer is a module, and each application in the application layer is a module. The module uses interfaces provided at the lower layer and interfaces provided by other modules at the same layer to complete specific functions, provides call interfaces for upper-layer and other modules at the same layer.

The interface here refers to how a function module is exposed to access specific functions provided to other modules. According to the characteristics of the C language, use *. c file implementation module function, use *. h File Exposure Unit Interface, in *. other external modules declared in the H file may be used functions, data types, global variables, Type Definitions, macro definitions, and constant definitions. external modules only need to include *. the corresponding functions can be used for H files. of course, the module can be subdivided into sub-modules. although the interface we mentioned here is different from the interface defined in COM (General Component Model), according to the discussion on the interface in COM, the modification of one module does not affect the modification of one module of other modules and does not cause the modification of other modules. Therefore, after the first release of the interface, modify *. the H file cannot cause other modules using this interface to need to be rewritten.

Basic Recommendations for file organization

A hierarchical and modular software development model is used. Each module can only use the interfaces provided by the layer and the next layer.
The file packages of each module exist in an independent folder. Generally, more than one module File is implemented, and the related files should be saved in one folder.
The Conditional compilation macro used for module reduction is saved in an independent file to facilitate software reduction.
Hardware-related code and operating system-related code are relatively independent from pure C code for software porting.
Separate the description and definition, and use *. the H File Exposure module must provide external functions, macros, types, constants, and global variables to ensure that the module is transparent to the outside. You do not need to know the specific implementation when using the module functions, once a file is published, you must be careful when modifying it,
The folder and file names must reflect the functions of the module. Therefore, the names must be meaningful.
The official and beta versions use a Unified File and use macros to control whether the test output is generated.
Necessary annotations are indispensable to improve the readability of the file.

The following rules are recommended for header files:

Header files cannot contain executable code or data definitions. They can only contain macro, type (typedef, struct, union, menu), data, and function declarations.
For example, the following code can be included in the header file:

# Define NAMESTRING "name"

Typedef unsign long word;

Menu

{

Flag1;

Flag2;

};

Typedef struct

{

Int x;

Int y;

} Piont;

Extent Fun (void );

Extent int;

The global variables and function definitions cannot appear in the *. h file. For example, the following code cannot be included in the header file:

Int;

Void Fun1 (void)

{

A ++;

}

The header file cannot contain local data (the data or functions used by the module are not used by other modules ). This is equivalent to the private member in the object-oriented programming, that is, only the functions used by the module, Data, do not use extent to declare in the header file, only the macro and constant used by the module, the type should not be declared in the header file. It should be in your own *. c file.
Includes some declarations to be used. Declare external data, functions, macros, and types in the header file.
Prevent Repeated inclusion. Use the following macro to prevent a header file from being repeatedly contained.
# Ifndef MY_INCLUDE_H

# Define MY_INCLUDE_H

<Header file content>

# Endif

Contains extern "C", so that the program can be compiled in the C ++ Compiler
# Ifdef _ cplusplus

Extern "C "{

# Endif

<Function declaration>

# Ifdef _ cplusplus

}

# Enfif

Variables and functions modified by extern "C" are compiled and connected in C language. The compilation method is not added when the extern "C" statement is declared. As an object-oriented language, C ++ supports function overloading, while C does not. The name of the function in the symbol library after being compiled by C ++ is different from that in the C language. For example, assume that the prototype of a function is:

Void foo (int x, int y); the name of this function in the symbol library after being compiled by the C compiler is _ foo, the C ++ compiler generates names such as _ foo_int_int (different compilers may generate different names, but all adopt the same mechanism, the new name is called "mangled name "). A name such as _ foo_int_int contains the function name, number of function parameters, and type information. C ++ relies on this mechanism to implement function overloading. For example, in C ++, the void foo (int x, int y) and void foo (int x, float y) functions generate different symbols, the latter is _ foo_int_float. Similarly, variables in C ++ support both local variables and class member variables and global variables. The class member variables of the program written by the user may have the same name as the global variables, which are distinguished. In essence, the compiler uses a unique name for the variables in the class when compiling, similar to the function processing. This name is different from the global variable name with the same name in the user program. Add the compilation and connection after the extern "C" declaration, and force the C ++ connector to follow the symbol _ foo link generated by the C compiler.

The combination is:

 

 

# Ifndef MY_INCLUDE_H
# Define MY_INCLUDE_H

# Ifdef _ cplusplus
Extern "C "{
# Endif
<Function declaration>
# Ifdef _ cplusplus
}
# Enfif

# Endif

 

When using this header file, you do not need to include any other prerequisite header files that use this header file. That is, the header file to be used is already included in this header file. For example, the area. h header file contains area-related operations. To use this header file, you do not need to include the point operation header file piont. h. You do not need to manually include piont. h when using area. h, because we have used # include "point. h" in area. h to include this header file.

More rules are required for header files used to expose interfaces:

1. One module and one interface, which cannot be used by several modules.

2. The file name is the same as the c file of the implementation module. Abc. c -- abc. h

3. Try not to use extern to declare some shared data. This approach is insecure. Users of other external modules may not fully understand the meaning of these variables. It is best to provide the GetPut function to access these variables.

4. Avoid including other header files unless they exist independently. This means that, in the header file used as an interface, try not to include the exposure of other modules *. header files in file C, but some header files that are not used to expose interfaces can be wrapped.

5. Do not include header files that are only used in executable files. These header files should be included in *. c files. This is the same as above, in order to improve the independence and transparency of interfaces.

6. The interface file should have user-oriented comments. Describe exposed content from the application perspective.

7. Do not modify the interface file after it is released. Make sure that the modification does not affect the user program.

Multiple code files use one interface file: This header file is used when a module considers that a file is too large. Add the following suggestions.

1. A module composed of multiple code files has only one interface file. These files are a module.

2. Use the file name under the module <system name> <Module name>

3. Do not abuse such files.

4. Sometimes there may be a few *. c file for common data *. h file, which is characteristic of *. the c file defines global variables, while the other *. c files are used in different scenarios.

5. If a module has several sub-modules, you can use a *. h file to expose the interface. In this file, use # include to include the interface file of each sub-module.

There is also a header file, descriptive header file, which does not need to have a corresponding code file. Most of these files contain a large number of macro definitions without exposing data variables and functions. These files provide the following suggestions:

1. Include some conceptual things.

2. naming method, defined function. h

3. does not contain any other header files.

4. No type is defined.

5. does not contain any data or function declaration.

This section describes some suggestions for the C header file. The following describes the C code file *. some suggestions for file c ,*. the c file is the content of the assembly code and machine code generated in the c language. Pay attention to the following suggestions:

1. naming method module name. c

2. Use static to modify local data and functions.

3. Do not use external. This is used in *. h and can be included.

4. When to define internal objects, make sure they are independent from other execution files.

5. This file must contain the corresponding function.