While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a

While I don't agree every single point (see below), one thing great about this document is that the author tried to really elaborate one's opinion. That makes a good point to start the discussion regardless of my own opinion. Thus I'll contribute back by giving my own judgement for every single item here: Absolute agreement * Always develop and compile with all warnings (and more) on * #include the definition of everything you use * Provide include guards for all headers to prevent double inclusion * Always comment `#endif`s of large conditional sections * Declare variables as late as possible * Be consistent in your variable names across functions * Minimize the scope of variables * Use `assert` everywhere your program would fail otherwise * Repeat `assert` calls; don't `&&` them together * C isn't object-oriented, and you shouldn't pretend it is Strong agreement with some obvious exceptions * Use `//` comments everywhere, never `/* ... */` * Comment non-standard-library `#include`s to say what symbols you use from them * No global or static variables if you can help it (you probably can) * Minimize what you expose; declare top-level names static where you can * Use `double` rather than `float`, unless you have a specific reason otherwise * Avoid non-pure or non-trivial function calls in expressions * Simple constant expressions can be easier to read than variables * Initialize strings as arrays, and use sizeof for byte size * Where possible, use `sizeof` on the variable; not the type * Document your struct invariants, and provide invariant checkers * Avoid `void *` because it harms type safety * If you have a `void *`, assign it to a typed variable as soon as possible * Only use pointers in structs for nullity, dynamic arrays or incomplete types * Avoid getters and setters Agreed but you need a few more words * Don't be afraid of short variable names [if the scope fits on a screen] * Explicitly compare values; don't rely on truthiness [unless values themselves are boolean] * Use parentheses for expressions where the operator precedence isn't obvious [but `&foo->bar` *is* obvious] * Separate functions and struct definitions with two lines [can use comments instead] * If a macro is specific to a function, `#define` it in the body [and `#undef` ASAP] * Only typedef structs; never basic types or pointers [or make them distinct enough, but ISO C stole a `_t` suffix] I do so or I see why but that's really a problem of C and its ecosystem instead * Use GCC's and Clang's `-M` to automatically generate object file dependencies * Avoid unified headers * Immutability saves lives: use `const` everywhere you can * Use `bool` from `stdbool.h` whenever you have a boolean value * Avoid unsigned types because the integer conversion rules are complicated * Prefer compound literals to superfluous variables * Never use array syntax for function arguments definitions * Don't use variable-length arrays * Use C11's anonymous structs and unions rather mutually-exclusive fields * Give structs TitleCase names, and typedef them * Never begin names with `_` or end them with `_t`: they're reserved for standards * Only use pointer arguments for nullity, arrays or modifications * Prefer to return a value rather than modifying pointers * Always use designated initializers in struct literals I do so but am not sure * Write to the most modern standard you can [we have no choice for many cases] * Program in American English [only applicable for native speakers] I see why but I think you are mislead * Don't write argument names in function prototypes if they just repeat the type [such case is very, very rare] * Use `+= 1` and `-= 1` over `++` and `--` [`++`/`--` should be read as succ/pred and should be exclusively used for pointers] * Don't use `switch`, and avoid complicated conditionals [switch is okay once you have enabled enough warnings] * Only upper-case a macro if will act differently than a function call [agreed in principle, but should define "differently" more broadly] * Always prefer array indexing over pointer arithmetic [and then you will be biten by index variable types, remember `ptrdiff_t`] That's really just a personal preference * We can't get tabs right, so use spaces everywhere [as long as mechanically enforcable, the choice itself is irrelevant] * Always put `const` on the right and read types right-to-left [too eyesore] * Use one line per variable definition; don't bunch same types together [will agree with some significant exceptions though] * Never change state within an expression (e.g. with assignments or `++`) [absolutely avoid functions, but `++` has its uses] * Always use brackets, even for single-statement block [rather a read-write trade-off; this may make some codes harder to read] * Never use or provide macros that wrap control structures like `for` [the example is very tame in comparison to actually problematic macros] * Don't typecast unless you have to (you probably don't) [while many typecasts can be easily removed, excess doesn't do actual harm] * Give enums `UPPERCASE_SNAKE` names, and lowercase their values [I would rather avoid enums for various reasons] * Use structs to name functions' optional arguments [maybe the author tried to say "avoid too many arguments" instead?] * If you're providing allocation and free functions only for a struct member, allocate memory for the whole struct [that complicates using struct as a value] Just no. * Never have more than 79 characters per line [100 or 120 do work equally well, you do need some limit though] * Define a constant for the size of every enum [would imply that all enum values are sequential, and that's not true!]