Write idiomatic, efficient C code with best-practice patterns

C: Idiomatic Efficiency Reference

When to Use

• Use this skill when the task matches this description: Language-specific super-code guidelines for c.

Table of Contents

1. Memory Management
2. Pointers & Arrays
3. Error Handling
4. Strings
5. Structs & Enums
6. Preprocessor & Headers
7. Anti-patterns specific to C

1. Memory Management {#memory}

// ❌ malloc without checking return value
char *buf = malloc(size);
strcpy(buf, src);

// ✅
char *buf = malloc(size);
if (!buf) return -ENOMEM;
memcpy(buf, src, size);

// ❌ Casting malloc result (unnecessary in C, hides missing #include)
int *p = (int *)malloc(n * sizeof(int));

// ✅
int *p = malloc(n * sizeof *p);

// ❌ free without nulling (dangling pointer risk in long-lived scope)
free(ptr);
// ... later code might use ptr

// ✅
free(ptr);
ptr = NULL;

// ❌ Forgetting to free on early-return paths
char *a = malloc(100);
char *b = malloc(200);
if (!b) return -1; // leaks a

// ✅ — single cleanup label
char *a = NULL, *b = NULL;
a = malloc(100);
if (!a) goto cleanup;
b = malloc(200);
if (!b) goto cleanup;
// ... use a, b ...
cleanup:
    free(b);
    free(a);

Use sizeof *ptr instead of sizeof(Type) - it stays correct when the type changes.

2. Pointers & Arrays {#pointers}

// ❌ Manual array size tracking
void process(int *arr, int len) { ... }
process(data, 10);

// ✅ — pass size alongside pointer, or use a struct
typedef struct { int *data; size_t len; } IntSlice;

// ❌ Pointer arithmetic where array indexing is clearer
*(arr + i) = value;

// ✅
arr[i] = value;

// ❌ VLA in production code (stack overflow risk, optional in C11+)
int arr[n];

// ✅
int *arr = malloc(n * sizeof *arr);
if (!arr) return -ENOMEM;
// ... use arr ...
free(arr);

3. Error Handling {#errors}

// ❌ Using magic numbers for error returns
if (do_thing() == -1) { ... }

// ✅ — define or use named error codes
#include <errno.h>
if (do_thing() < 0) {
    perror("do_thing");
    return errno;
}

// ❌ Deeply nested error checks
int r1 = step1();
if (r1 == 0) {
    int r2 = step2();
    if (r2 == 0) {
        int r3 = step3();
        // ...
    }
}

// ✅ — early return / goto cleanup
if (step1() < 0) goto fail;
if (step2() < 0) goto fail;
if (step3() < 0) goto fail;
return 0;
fail:
    cleanup();
    return -1;

goto cleanup is idiomatic C for resource teardown - don't avoid it out of principle.

4. Strings {#strings}

// ❌ strcpy without bounds checking
strcpy(dest, src);

// ✅
strncpy(dest, src, sizeof(dest) - 1);
dest[sizeof(dest) - 1] = '\0';
// or better: snprintf(dest, sizeof(dest), "%s", src);

// ❌ strcmp misuse
if (str == "hello") { ... } // compares pointers, not content

// ✅
if (strcmp(str, "hello") == 0) { ... }

// ❌ Building strings with repeated strcat (O(n²))
char result[1024] = "";
for (int i = 0; i < n; i++) {
    strcat(result, items[i]);
}

// ✅ — track write position
char result[1024];
int pos = 0;
for (int i = 0; i < n && pos < (int)sizeof(result); i++) {
    pos += snprintf(result + pos, sizeof(result) - pos, "%s", items[i]);
}

Prefer snprintf over sprintf - always.

5. Structs & Enums {#structs}

// ❌ Bare struct requiring `struct` keyword everywhere
struct point { int x, y; };
struct point p = {1, 2};

// ✅
typedef struct { int x, y; } Point;
Point p = {1, 2};

// ❌ Uninitialized struct
Point p;
use(p.x); // UB

// ✅
Point p = {0};

// ❌ Magic integer constants
if (state == 3) { ... }

// ✅
typedef enum { STATE_IDLE, STATE_RUNNING, STATE_DONE } State;
if (state == STATE_DONE) { ... }

6. Preprocessor & Headers {#preprocessor}

// ❌ Macro where inline function works (no type safety, double eval)
#define MAX(a, b) ((a) > (b) ? (a) : (b))
MAX(x++, y) // x incremented twice if x > y

// ✅
static inline int max_int(int a, int b) { return a > b ? a : b; }

// ❌ No include guard
// my_header.h
struct Foo { int x; };

// ✅
#ifndef MY_HEADER_H
#define MY_HEADER_H
struct Foo { int x; };
#endif
// or: #pragma once (widely supported, not standard)

Keep macros for conditional compilation and constants. Use static inline for logic.

7. Anti-patterns specific to C {#antipatterns}

Limitations

• These are language-specific guidelines and do not cover overall architectural decisions.
• Over-compression might reduce readability; apply judgement.