Yep.

Use some of the -W* flags (-Wall -Wpedantic -Wconversion, ...) and specify the standard -std=c90.

Avoid undefined behaviors:

- https://en.cppreference.com/w/c/language/behavior

- https://wiki.sei.cmu.edu/confluence/display/c

(Also use cppcheck, valgrind, gdb, astyle, make, ...)

Done.

Fun fact: JS and C are both standardized by ISO.

And always use "-fwrapv -fno-strict-aliasing -fno-delete-null-pointer-checks". Those are source of the hardest to reason about UB and the small performance benefit is not worth the risk. I would love to always be certain I haven't accidentally hit UB, but that's equal to the halting problem, so for peace of mind, I just ask the compiler for a slightly safer variant of the language.

P.S. and old code definitely needs them, as at the time compilers didn't optimize so aggressively and lots of code does weird stuff with memory, shifts, etc.

Have a look at Apache 1 (C) or KDE 1 (C++); it'd be interesting to see what you think of those codebases, and they can certainly predate 2001.

Maybe it's next to impossible to write C code that isn't badly written

Or maybe we have too many developers that treat language of their choice as a religion.

>To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

-- https://www.bell-labs.com/usr/dmr/www/chist.html

Unfortunately since 1979, majority of C devs think they know better.

C code is of course close to the hardware, which as always, has benefits and drawbacks.