I appreciate the intent, C has become its own thing with its own set of conventions, and people still writing "C/C++" often reveal that they don't have a clue about either.

I think many C programmers might disagree with large parts of this, however. Some things that caught my eye that might be controversial:

> Wrap your structs in a typedef

The only reason to do this that's mentioned is "annoyance", which I think is a weak reason if you have the kind of problem for which you're considering to use C. The author already mentions that it has a weird interaction with forward declarations. It's my understanding that many C codebases don't do this, simply to be more explicit about what's a struct and what's not, and to avoid typedef explosion.

> the POSIX standard reserves the ‘_t’ postfix for its own typenames to prevent collisions with user types – make of that what you will ;)

IMO, that's not something to casually dismiss with a smiley. If it's reserved, don't do it.

> Typedef only creates a weak type alias not a proper new type (it’s really not much better than a preprocessor define), meaning there’s no warning when assigning to a different type from the same base type

The point is somewhat valid, but the author seems a bit confused about terminology here. It's not "a different type from the same base type", instead, it's a different name for the same type. The comparison with the preprocessor is unwarranted.

> Be (somewhat) afraid of pointers

Why? The following rant about RAII doesn't really give that many clues. Handles can have a performance penalty vs pointers -- or be a performance benefit, this really depends on the details.

Also, this is where it might have been helpful to go into different conventions about allocations, whether the caller or callee should allocate, etc.