C Programming Best Practices: 15 Rules for Clean, Safe, Maintainable Code

The compiler catches most bugs before they become runtime failures — but only if you ask it to. Without warning flags, GCC will happily compile code that uses uninitialized variables, calls functions without declarations, or silently converts between incompatible types. Treat warnings as errors in production code.

gcc program.c -o program

gcc -Wall -Wextra -Wshadow \
    -Werror -g -std=c11 \
    program.c -o program

AddressSanitizer (ASan) detects memory errors at runtime with precise line numbers — buffer overflows, use-after-free, double-free, and stack overflows. It runs ~2x slower than normal, so it is used during development and testing, not in production.

# Development: all warnings + sanitizers
gcc -Wall -Wextra -g -std=c11 \
    -fsanitize=address -fsanitize=undefined \
    program.c -o program_dev

# Release: optimized, no sanitizers
gcc -Wall -Wextra -O2 -std=c11 \
    program.c -o program

void main() is non-standard and produces undefined behavior. The OS needs the exit code to determine success or failure. Shell scripts and CI systems rely on it. return 0 signals success; any non-zero value signals failure.

void main() {
    printf("Hi\n");
// no return
}

#include <stdlib.h>
int main(void) {
    printf("Hi\n");
    return EXIT_SUCCESS;
}

Without braces, adding a second statement to an if-body silently puts it outside the conditional — one of the most common refactoring bugs. Apple's "goto fail" SSL vulnerability (CVE-2014-1266), which affected millions of devices, was caused by exactly this mistake.

if (error)
    log("fail");
    cleanup();  // ALWAYS runs

if (error) {
    log("fail");
    cleanup();
}

Every included header adds its contents to your translation unit, increasing compile time. More importantly, headers can introduce name conflicts — two headers defining a macro with the same name produces unpredictable behavior.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
// Only uses printf

#include <stdio.h>
// Only include what you use

Global variables are accessible from any function, making it impossible to understand a function's behavior in isolation. A function that depends on global state cannot be tested without setting up that state. Pass what a function needs as parameters; return what it computes as a return value.

int total = 0;  // global

void add(int x) {
    total += x;  // reads/writes global
}

int add(int total, int x) {
    return total + x;  // pure function
}

Single-letter or abbreviated names save a few keystrokes but cost hours of debugging. Code is read far more often than it is written. A name should tell the reader what the thing represents without requiring context.

int n, tc, avg;
double calc(int a, int b);

int student_count, total_score, class_average;
double calculate_average(int total, int count);

C naming convention summary: variables and functions → snake_case; macros and constants → ALL_CAPS; typedef names → often end in _t (e.g. node_t); struct tags → snake_case or PascalCase depending on your style guide.

Comments that just repeat what the code says add noise without value. Comments explaining why a decision was made, what a non-obvious algorithm does, or what invariant the code maintains — those are genuinely useful and save hours for future maintainers (including yourself six months later).

/* increment i by 1 */
i++;

/* set x to 0 */
x = 0;

/* Bias by 1 to convert 0-indexed to 1-indexed
   output expected by the report format */
i++;

/* Reset accumulator before next batch */
x = 0;

A literal number in the middle of code — a "magic number" — forces readers to guess its meaning. Give every non-obvious constant a name. UPPER_CASE for macros signals "this is a compile-time constant, not a variable."

if (score >= 90) grade = 'A';
char buf[4096];
for (i = 0; i < 52; i++) { }

#define GRADE_A_THRESHOLD  90
#define BUF_SIZE           4096
#define DECK_SIZE          52

if (score >= GRADE_A_THRESHOLD) grade = 'A';
char buf[BUF_SIZE];
for (i = 0; i < DECK_SIZE; i++) { }

Uninitialized variables contain garbage values — whatever was in that stack memory before. Reading an uninitialized variable is undefined behavior in C. Initializing at declaration prevents the entire class of "used before initialized" bugs.

int count;
double total;
/* ... 20 lines ... */
count++;  // undefined if used before set

int    count = 0;
double total = 0.0;
count++;

A function that does multiple things is hard to name, hard to test, and hard to debug. If you struggle to name a function without using "and" in the name, it is doing too much. The Linux kernel style guide targets functions under 40 lines; aim for under 30.

const on a pointer parameter tells callers and future maintainers that the function will not modify the data — it is a read-only operation. This prevents accidental modifications and enables the compiler to catch errors if your own code accidentally tries to modify it.

int strlen_custom(char *s) {
    // does NOT modify s, but misleads
}

int strlen_custom(const char *s) {
    // compiler enforces: cannot modify *s
}

These functions can fail. malloc returns NULL when memory is exhausted. fopen returns NULL when the file doesn't exist or permissions are denied. scanf returns fewer items than expected when input is malformed. Ignoring failures leads to null pointer dereferences (crashes) or silent incorrect behavior.

int *p = malloc(1000 * sizeof(int));
p[0] = 42;  // crash if malloc failed

int *p = malloc(1000 * sizeof(int));
if (!p) { perror("malloc"); return 1; }
p[0] = 42;

Forgetting to free causes memory leaks — the program consumes more and more memory over time. Freeing the same pointer twice (double-free) corrupts the heap and can be exploited as a security vulnerability. Set the pointer to NULL after freeing to make double-free detectable.

int *data = malloc(n * sizeof(int));
if (!data) { perror("malloc"); return 1; }

/* use data ... */

free(data);
data = NULL;   // makes double-free detectable: free(NULL) is safe no-op

Buffer overflows are the most common class of C security vulnerabilities. The unsafe functions (sprintf, strcpy, gets) have no way to limit output size. Their safe alternatives (snprintf, strncpy, fgets) accept a size parameter that prevents writing beyond the buffer.

char buf[32];
sprintf(buf, "%s", user_input);  // overflow
strcpy(buf, user_input);         // overflow
gets(buf);                        // removed in C11

char buf[32];
snprintf(buf, sizeof(buf), "%s", input);
strncpy(buf, input, sizeof(buf) - 1);
buf[sizeof(buf) - 1] = '\0';  // ensure termination
fgets(buf, sizeof(buf), stdin);