32 Essential C Programming Practices for Clean, Maintainable Code

1. Copyright and Version

Good programmers add copyright and version information to each function and file. Example header comment for a C file:

/************************************************************************
* File: network.c
* Description: Network communication functions
* Author: Hao Chen, 2003-02-03
* Version: 1.0
* Modification History:
************************************************************************/

Similar comments for each function improve overall readability and maintenance.

2. Indentation, Spaces, Newlines, Blank Lines, Alignment

Use a TAB or four spaces for each indentation level. Add spaces around operators and after commas. Break long statements into multiple lines and align related code blocks. Example: ha = (ha * 128 + *key++) % tabPtr->size; Proper formatting makes code easier to read.

3. Code Comments

Every file, function, variable, algorithm, and code block should have clear comments explaining its purpose, inputs, outputs, and any special considerations. Avoid hard‑coded messages; use a centralized error‑handling system.

4. Function [in][out] Parameters

Validate all input pointers before use and use assertions where appropriate. For output parameters, check the returned values after the call.

5. Return Value Checks for System Calls

Always verify the return values of functions like fopen, malloc, or socket calls before using them.

6. Error‑Handling Statements

Prefer early error detection and return, avoiding deep nested else blocks. Example:

if (ch < '0' || ch > '9') {
    printf("error ......
");
    return FALSE;
}
/* normal processing */

7. Modifying Others' Code

When fixing existing code, comment out the original lines and add new ones with clear attribution instead of deleting the original code outright.

8. Extract Repeated Code into Functions or Macros

Group similar code fragments into reusable functions or macros to avoid duplication and simplify maintenance.

9. Parentheses in Expressions

Use parentheses to make operator precedence explicit, especially in complex conditional statements.

10. Const in Function Parameters

Mark pointer parameters as const when the function only reads the data, clarifying intent and preventing accidental modification.

11. Limit Number of Function Parameters

Prefer no more than six parameters; use a struct to group related arguments.

12. Explicit Return Types

Always specify the return type (e.g., void, int) even for functions that default to int in older C standards.

13. Goto Usage

Avoid goto except for centralized error‑cleanup patterns, such as freeing resources before exiting a function.

14. Macro Usage

Define macros carefully with parentheses around parameters to avoid unexpected evaluation order. Example safe MAX macro:

#define MAX(a,b) ((a) > (b) ? (a) : (b))

15. Static Keyword

Use static for file‑local variables and functions to limit their visibility and for persistent local variables that retain state across calls.

16. Function Size

Keep functions under 300 lines; ideally under 100 lines. Split large functions into smaller, single‑purpose ones.

17. Typedef Usage

Use typedef to create clear, portable type aliases (e.g., typedef unsigned int UINT32_T;).

18. Define Constants with Macros

Replace magic numbers with named macros, e.g., #define MAX_USER_CNT 120, to improve readability and ease future changes.

19. Do Not End Macros with a Semicolon

Define macros without a trailing semicolon; the caller adds it if needed.

20. Logical Operators Short‑Circuit

Remember that || stops evaluation after a true operand and && stops after a false operand, preventing unnecessary side effects.

21. Prefer for Over while

Use for loops when the initialization, condition, and increment are related, as it makes the loop intent clearer.

22. Use sizeof on Types, Not Variables

When allocating memory, write sizeof(int) * n instead of sizeof(var) to avoid mistakes with pointer sizes.

23. Pay Attention to Compiler Warnings

Treat all warnings as errors; they often reveal hidden bugs such as unused variables, implicit function declarations, or unsafe pointer casts.

24. Debug vs. Release Builds

Wrap debug output in a macro controlled by a compile‑time flag (e.g., #ifdef DEBUG) so that release builds contain no debugging code.