C Coding Style Cheat Sheet (Version 1.0.4)

Compact version of the C Coding Style.

1. General Rules

Use "#pragma once".
Project headers → external headers → system headers.
Blank line between groups.
Same spacing rules in headers and implementations.
Two blank lines between different kinds of sections such as includes, type definitions, and function declarations or definitions.

Max 80 characters (line break counts, so max 79 code chars).
Indent continuation lines when breaking an expression.
Do not indent again when breaking the same expression multiple times unless breaking a sub-expression.
Break before operators (+, -, *, /, %, &&, ||, &, |, ^, <<, >>).
Break after assignment (=).
Prefer breaking after assignment (=) to breaking before another operator.
Break before comparison operators (==, !=, <, >).
Break before reference operators (. and ->).
When breaking at (, [, or {, break directly after it.
Never reduce indentation by more than one level at once.
Broken [] expressions and {} constructs close on their own unindented line.
In a broken parenthesized sub-expression, close on the final expression line if it starts beside (; otherwise close on an unindented line.
Broken block heads: final line ends with ), { is on its own line.

const instead of #define for true constants (file scope only).
Constants ALL_CAPS, variables camelCase.
static remains with the type when it applies to a variable.
Names of output variables must always start with out.
Declare variables at first use and always initialize them; use a safe default when necessary.
If the same literal value is used in more than one place, define a named constant for it instead of repeating the literal.
Use size_t for array indices and counters.
Avoid signed unless needed.
char only for characters, never for byte-sized ints.
Make no assumption about char being signed or unsigned.
Enums/structs start uppercase, { on same line, one field per line.
Enum values suffixed with enum name, separated by underscore.
One blank line between adjacent multi-line struct definitions.
Adjacent single-line struct definitions need no blank line.
Do not typedef all structures and enums.
typedef only opaque types and enums used as options.
One blank line between adjacent multi-line typedefs.
Adjacent single-line typedefs need no blank line.

External linkage: Uppercase. File-local: lowercase.
No space between a function name and its opening parenthesis.
Calls also have no spaces inside their parentheses; declarations and definitions do.
One blank line between adjacent function declarations in both header and implementation files.
Two blank lines between groups of function declarations.
Keep calls/declarations/definitions on one line when they fit; otherwise start the list on the line after ( and split it only when necessary.
Use up to 3 arguments/parameters per line for at most 2 lines; beyond that, use one per line.
Broken calls close after the final argument; declarations close on their own unindented line.
Function attributes, including static, are on the line above a function.
Two blank lines after function, three between groups.
One blank line between instruction groups inside functions.

{ on same line as if/for/while (unless broken).
No braces for single-statement branches (unless broken).
An if with an else uses braces for both branches, even for one statement.
Use braces for multi-statement branches.
Multi-line conditions: ) on final condition line, { on next line.
In do-while loops, break the while keyword as you would break a function call.
One line may contain two statements only if second is control flow.
Prefer early returns.
In blocks with many early returns, add a blank line after each when code follows.
goto only for cleanup.
switch: indent case and body. Use { } unless simple single-line.
Each case ends with break/return/goto.
Fallthrough requires comment or the use of a fallthrough statement.
return only one value; if expression, wrap in ( ).

Use //, /* ... */ only mid-line.
Prefer comments above a line if referring to the line as a whole.
Prefer end-of-line comments if explaining an assigned value.
Documentation: /** ... */ before functions, indented, no * prefix per line.
Normal comments do not need full sentences.
A single-sentence normal comment omits final punctuation.
Multi-sentence normal comments end each sentence with punctuation.
Documentation comments must use full sentences.
Use @param when the parameter's purpose or constraints are not obvious from its type and name alone.
Use [in] and [out] with @param only when the function has output parameters. Omit them when all parameters are inputs.
Indent continuation lines for @param descriptions.
Prefer @returns over @return.
Indent continuation lines for inline @returns descriptions.
An @returns tag without an inline description starts a block.
Block content starts on the following line without continuation indentation.
Return blocks may contain multiple paragraphs. Indent lists inside blocks for readability.
Use backticks for code and fenced blocks (\\\`) for code samples.
Markdown emphasis using _ and ** is permitted.

Keep similar adjacent blocks visually consistent, even if that slightly breaks the rules.