Modular suggestions for C language in large projects

one large software projects generally contain many complex functions, implementing this project is not a single Program member, A team is often required division of labor cooperation. In addition, in a complete project that focuses on C Code , you often need to add code in other languages. For example, the hybrid use of C code and assembly code, and the simultaneous use of C files and C ++. These increase the complexity of a software project. To improve the software quality, reasonable organization of various codes and files is very important . the purpose of organizing code and files is to make teamwork more effective, it enables software projects to have good scalability, maintainability, portability, scalability, and testability to prevent errors and improve software stability.

software projects generally adopt a hierarchical structure 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 the Calling Interface for its upper layer ; A module is a unit that completes a function at 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. Under normal circumstances, there are more than one module File. 
  The file should be saved in a folder.
  

• Conditional compilation macros used for module reduction are stored in an independent file, which facilitates 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,
  
• Folder and file naming should reflect the module functionsSo the name must be a meaningful name.
  
• The official and beta versions use a Unified File and use macros to control whether the test output is generated.
  
• Necessary comments are indispensableTo improve file readability.
  

The following rules are recommended for header files:

1. 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 ++;

}

1. 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.
   

1. Includes some declarations to be used. Declare external data, functions, macros, and types in the header file.
   

1. 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

1. IncludeEXtern "C" enables the program to 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 Function
Foo (int x, int y) and void Foo (int x, float y) are generated in different ways. 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
 

 

1. 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 in area. h.
   "Point. H" contains this header file.

Expose interface header filesYou also need to refer to more rules:

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 functions.GetputAccess 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 thinks that a file is too large.AddThe 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 fileThis header file does not need 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.

The following describes some suggestions for the c header file.* Some Suggestions for the. c file, * The. c file is the content that generates assembly code and machine code in 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. The file must contain the corresponding function.