Some of this seems like horrendously bad advice:<p>- Using fixed width integers in for loops seems like a fabulous way to reduce the portability of code<p>- the statements in &quot;C allows static initialization of stack-allocated arrays&quot; are _not_ equivalent, one is a bitwise zeroing while the other is arithmetic initialization. On some machines changing these statements blindly will cause a different bit pattern to end up in memory (because there are no requirements on the machine&#x27;s representations for e.g. integers or NULL or ..). There are sound reasons why the bitwise approach could be preferred, for example, because a project has debug wrappers for memset that clearly demarcate uninitialized data<p>- the statements in &quot;C99 allows variable length array initializsers&quot; aren&#x27;t even slightly equivalent. His suggestion uses automatic storage (and subsequently a stack overflow triggered by user input -- aka. a security bug)<p>- &quot;There is no performance penalty for getting zero&#x27;d memory&quot; this is bullshit. calloc() might optimize for the case where it is allocating from a page the OS has just supplied but I doubt any implementation ever bothered to do this, since it relies on the host OS to always zero new pages<p>- &quot;If a function accepts arbitrary input data and a length to process, don&#x27;t restrict the type of the parameter.&quot; the former version is in every way more self-documenting and consistent with the apparent function of the procedure than his use of void<i>. It also runs counter to a rule from slightly more conservative times: avoid void</i> at all costs, since it automatically silences all casting warnings.<p>Modern C provides a bunch of new things that make typing safer but none of those techniques are mentioned here. For example word-sized structs combined with struct literals can eliminate whole classes of historical bugs.<p>On the fixed width integers thing, the size of &#x27;int&#x27;, &#x27;long&#x27; and &#x27;long long&#x27; are designed to vary according to the machine in use. On some fancy Intel box perhaps there is no cost to using a 64bit type all the time, but on a microcontroller you&#x27;ve just caused the compiler to inject a software arithmetic implementation into your binary (and your code is running 100x slower too). He doesn&#x27;t even mention types like intfast_t designed for this case, despite explicitly indicating &quot;don&#x27;t write C if you have to&quot;, which in 2016 pretty commonly means you&#x27;re targeting such a device