C Language Programming specification

C Language Programming specification

Range

This specification applies to all software in the company that uses C language encoding. This specification shall take effect from the date of release, and the New and modified

Code should comply with this specification.

Introduction

This specification has established the basic Principles, rules and recommendations for the preparation of C language programs. Clear, concise, testable, safe, and program-efficient from code

Rate, portability in various aspects of C language programming has been given specific guidance.

4 0 Specification Development Statement 0.1 preface

In order to improve the product code quality, instruct the software developers to write a concise, maintainable, reliable, testable, efficient, portable

Code, Programming specification revision the Working Group analyzed and summed up various typical coding problems of our company, and referenced the industry programming standard in recent years

Results, the Division I 1999 edition of the programming specifications for carding, optimization, refresh, compiled this specification.

This specification will be divided into full and compact versions, and the full version will include more examples, specification explanations, and reference materials (what & why),

The compact version will contain only the Rules section (what) for review.

At the end of this specification, some of the industry's more excellent programming specifications are listed as extension reading reference materials. 0.2 Code general principles

1. Clear first

Clarity is an essential feature of a program that is easy to maintain and easy to refactor. The code is first read, and good code should be like the text

Chapter the same audible recitation came out.

At present, the cost of software maintenance period is the 40%~90% of the whole life cycle cost. According to industry experience, maintenance period changes the cost of code, small department

The system is 5 times times the development period, and large systems (1 million lines of code or more) can reach 100 times times. Industry surveys have pointed out that the development group averages about

Half the workforce is used to make up for past mistakes, instead of adding new features to help companies improve their competitiveness.

"The program must be written for the person who read it, but for machine execution." "--harold Abelson and Gerald Jay

Sussman

"Writing programs should be people-oriented, computer second." "--steve McConnell

This specification passes the principles in the following article (such as good code can be explained by itself, not through the annotation can easily read/header file suitable for placement

The declaration of an interface, which is not suitable for placing implementations/except for common abbreviations, does not use the abbreviation of words, must not use Hanyu Pinyin,

Then, such as preventing local variables from having the same name as global variables, the importance of clarity is clarified.

In general, the readability of the code is higher than the performance, only if you determine the performance is a bottleneck, you should actively optimize.

2, concise for the United States

Simplicity is easy to understand and easy to implement. The longer the code is difficult to understand, the easier it is to introduce errors when you modify it. The more code you write

More, meaning that the more mistakes there is, the lower the reliability of the code. Therefore, we advocate that by writing concise and clear

Code to improve the reliability of your code.

Obsolete code (not called functions and global variables) should be purged in time, and repeated code should be refined as a function.

This specification is passed after the principles (such as file should be responsible for single/one function to complete only one function), rules (repeat code should do

The importance of simplicity may be distilled into functions/avoidance functions that are too long, and no more than 50 lines of new functions.

3, choose the right style, and the original style of the code to maintain the same

The benefits of sharing the same style by the product owner far outweigh the costs of unification. Coding rules in the company

Under the guidance of van, it is a very important skill to carefully orchestrate the code to make the code as clear as possible. If you refactor/modify other styles

Code, it is wiser to continue writing code based on the existing style of the existing code, or to use the format conversion tool to turn

5

Change to the internal style of the company. 0.3 Standard implementation, interpretation

This specification has established the basic Principles, rules and recommendations for the preparation of C language programs.

This specification applies to all software in the company that uses C language encoding. This specification shall take effect from the date of release, and will be revised and modified

The code should comply with this specification.

This specification is issued and maintained by the quality system. Problems encountered in implementation, you can go to the forum

discussed on http://hi3ms.huawei.com/group/1735/threads.html.

In some cases (such as BSP software) that violate the rules given in this document, the relevant team must pass a formal process to evaluate

The individual programmer shall not violate the relevant rules of this specification in the part of the violation of the rules of audit and decision. 0.4 Term Definitions

Principle: Must adhere to the guiding ideology when programming. Rule: A convention that enforces mandatory compliance when programming. Recommendation: A convention that must be considered when programming.

Note: Make the necessary explanations for this principle/rule/suggestion.

Example: give examples of this principle/rule/recommendation from positive and reverse two aspects.

Extended reading material: a reference material that suggests further reading. 1 Header Files

Background

For C language, the design of the header file embodies most of the system design. Unreasonable header file layout is the root of too long compilation time

Because, the unreasonable header document actually reflects the unreasonable design.

Term definition:

Dependencies: This section refers specifically to compilation dependencies. If the x.h contains Y.h, it is called X dependent Y. A dependency is conducted, as x.h contains Y.h,

And Y.h contains the z.h, then x relies on z through Y. Dependency will lead to a rise in compilation time. Although dependence is unavoidable, it is also necessary

Required, but poor design will cause the entire system dependencies are extremely complex, so that any one file changes to be recompiled

The entire system, resulting in a huge rise in compilation time.

In a well-designed system, modifying a file requires only recompiling several, or even a file.

A product has done an experiment, the implementation of all functions through the tool annotation, the compilation time of less than 10%, the original

Because, in a contains b,b contains c,c contains D, almost every source file contains all the header files of the project group, causing

Most of the compilation time is spent on parsing header files.

A product has a "good practice" for merging the. c files into a larger. c file by using tools to significantly improve

Compilation efficiency. The root cause is that the number of header file resolutions is reduced by merging the. c file. However, such "excellent practice"

is a kind of damage to the reasonable division. c file.

Most products modify a code, need to compile the entire project, for TDD and other practices, requirements for module-level compile-time

Control at the second level, even if the use of distributed compilation is difficult to achieve, and ultimately still need a reasonable division header file, and header files between

Contains relationships that fundamentally reduce compilation time.

6

The "Google C + + Style Guide" 1.2 Header file Dependencies section also gives a similar description:

If you include the header file Aa.h, you introduce a new dependency: Once Aa.h is modified, any direct and indirect inclusion of AA.H code will be

Recompile. If Aa.h also contains other header files such as bb.h, any changes to bb.h will result in all generations that contain aa.h

Code is recompiled, in the Agile development mode, the coding will be frequently built, the long compilation time will greatly hinder the frequent construction. Because

In this case, we tend to reduce the inclusion header file, especially the header file in the header file, to control the compile time after the code changes.

Reasonable header File Division embodies the idea of system design, but from the point of view of programming norms, there are still some common methods to

Reasonable planning header file. Some of the methods described in this section will help you to plan your header files properly.

The principle 1.1 header file is suitable for placing the interface declaration, which is not suitable for placement implementations.

Description: The header file is the external interface of a module (module) or unit. The header file should place a statement to the outside, such as external

Provides function declarations, macro definitions, type definitions, and so on.

Internally used functions (equivalent to the private method of a class) declaration should not be placed in the header file.

macros, enumerations, and structural definitions used internally should not be placed in the header file.

The variable definition should not be placed in the header file, but should be placed in the. c file.

The declaration of a variable should not be placed in the header file, that is, try not to use global variables as an interface. A variable is the interior of a module or unit

Implementation details should not be exposed directly to the outside by means of a declaration in the header file, and should be exposed externally by means of a function interface. That

To make it necessary to use global variables, you should define global variables only in. c, and only declare variables to be global in. h.

Extended reading materials: "C Language Interface and implementation" (David R. Hanson Fu Zhou Peng Zhang Kunqi authoritative translation machinery industry out

Edition Society January 2004) (English: "C Interfaces and implementations")

Principle 1.2 documents should have a single responsibility.

Description: The header file is too complex, relying too complex is the main reason for the compilation time is too long. Many of the existing code has a large header file,

Too much responsibility, coupled with the problem of circular dependencies, can lead to the use of a macro in. c and a more than 10 header file.

Example: The following is the header file for a platform definition word type:

#include <vxworks. H>

#include <kernellib. H>

#include <semlib. H>

#include <intlib. H>

#include <tasklib. H>

#include <msgqlib. H>

#include <stdarg. H>

#include <fiolib. H>

#include <stdio. H>

#include <stdlib. H>

#include <ctype. H>

#include <string. H>

#include <errnolib. H>

#include <timers. H>

#include <memlib. H>

#include <time. H>

#include <wdlib. H>

#include <syslib. H>

#include <taskhooklib. H>

#include <rebootlib. H>

...

7

typedef unsigned short WORD;

...

This header file not only defines the basic data type Word, but also contains stdio.h syslib.h and other infrequently used headers. If the work

There are 10,000 source files in the process, and 100 of the source files use stdio.h printf, because the header file is too large,

And word is the one that every file must contain, which leads to stdio.h/syslib.h and so may be unnecessarily unfolded 9,900 times, the big

Greatly increased the project's compile time.

The principle 1.3 header file should be included in a stable direction.

Description: The header file's inclusion relationship is a dependency, in general, the unstable module should be allowed to rely on the stable module, so that when the instability

When a fixed module changes, it does not affect (compile) the stable module.

As far as our products are concerned, the direction of dependence should be: the product depends on the platform, and the platform relies on the standard library. Code for a product line platform

has already included the product header file, which is a very bad example of how the platform cannot be compiled, published, and tested separately.