Essential C Coding Standards for Clear, Safe, and Maintainable Code

Reading others' code inevitably requires adhering to language coding standards, which, while not mandatory, become de‑facto conventions for all developers.

Following these conventions improves readability, reduces errors, and reflects code quality.

General Principles

Clarity First : Code should be as readable as prose, spoken aloud.

Simplicity is Beauty : Short, understandable code reduces bugs; remove dead code and refactor duplicates into functions.

Consistent Style : Align with existing project style; use format‑conversion tools if needed.

Header Files

Principle 1.1 Header files contain only interface declarations, not implementations.

Principle 1.2 Keep header responsibilities single to avoid long compile times.

Principle 1.3 Include only stable headers to prevent cascading recompilations.

Rule 1.1 Each .c file should have a same‑named .h for public interfaces; omit the file if no public API is needed.

Rule 1.2 Prohibit circular header dependencies.

Rule 1.3 Do not include unused headers.

Rule 1.4 Headers must be self‑contained.

Rule 1.5 Use include guards ( #ifndef FILENAME_H … #endif) with unique names.

Rule 1.6 Never define variables in headers.

Rule 1.7 Access external symbols via header declarations, not extern in source files.

Rule 1.8 Do not include headers inside extern "C" blocks.

Suggestion 1.1‑1.4 Organize modules in directories, provide a single public header per module, avoid non‑standard extensions, and keep include ordering uniform.

Functions

Principle 2.1 Each function should perform a single task.

Principle 2.2 Refactor duplicate code into functions.

Rule 2.1 New functions should not exceed 50 non‑blank, non‑comment lines.

Rule 2.2 Limit nesting depth to four levels for new functions.

Rule 2.3 Re‑entrant functions must avoid shared mutable state or protect it with mutexes.

Rule 2.4‑2.6 Define responsibility for parameter validation, handle all error codes, and keep fan‑in/fan‑out reasonable (fan‑out < 7).

Suggestion 2.1‑2.6 Use const for immutable parameters, minimize globals, validate all inputs, limit function parameters to five, avoid variadic functions except for logging, and mark internal functions static.

Identifiers

Principle 3.1‑3.2 Names must be clear, meaningful, and avoid obscure abbreviations or pinyin.

Suggestion 3.1‑3.10 Adopt a unified naming style per project, avoid numeric suffixes unless logical, omit module prefixes, keep file names lowercase, prefix globals with g_, statics with s_, and use noun‑or‑adjective‑plus‑noun forms.

Variables

Principle 4.1‑4.3 Each variable has a single purpose; avoid globals.

Rule 4.1‑4.3 Prevent name clashes, respect byte order in communication structs, and never use uninitialized variables.

Suggestion 4.1‑4.5 Centralize mutable state, use interface‑based access, initialize variables close to use, define clear init order, minimize implicit casts, and avoid unnecessary type conversions.

Macros and Constants

Rule 5.1‑5.4 Enclose macro arguments in parentheses, wrap multi‑statement macros in do{…}while(0), avoid side‑effects, and eliminate magic numbers.

Suggestion 5.1‑5.3 Prefer functions over macros, use const for constants, and avoid flow‑control statements inside macros.

Quality Assurance

Principle 6.1‑6.4 Prioritize correctness, simplicity, maintainability, reliability, testability, performance, portability, and personal coding comfort.

Rule 6.1 Prohibit out‑of‑bounds memory access.

Rule 6.3 Never reference freed memory.

Rule 6.4 Guard against off‑by‑one errors.

Suggestion 6.1‑6.4 Release allocated memory before function exit, always provide an else branch, avoid goto, and check for overflow/underflow.

Efficiency

Principle 7.1‑7.2 Optimize only after ensuring correctness, simplicity, and maintainability.

Suggestion 7.1‑7.4 Move invariant calculations out of loops, avoid strided accesses on large arrays, use object pools, and inline small frequently‑called functions.

Comments

Principle 8.1‑8.3 Good code should be self‑explanatory; comments clarify intent, not repeat code.

Rule 8.1‑8.8 Keep comments up‑to‑date, place them above code, use a consistent format (e.g., Doxygen), and avoid ambiguous abbreviations.

Expressions, Safety, and Testing

Ensure expressions yield the same result regardless of evaluation order, validate all user input, use safe string functions ( strncpy, snprintf, etc.), avoid integer overflow, sign errors, truncation, mismatched format specifiers, and command injection. Write unit tests alongside code, focusing on behavior rather than implementation details.

Portability and Miscellaneous

Do not redefine standard library identifiers, avoid embedded assembly unless necessary, and follow the recommended coding conventions to maximize portability and reusability.