Generally a wonderful set of minimalistic rules, much could carry over beyond C.<p>Except for: "OMG-API-3: Unsigned integers are preferred over signed".. I feel they're on the wrong side of history with this one.<p>"Prefer unsigned" only works if you can do 99% of your codebase this way, which, besides LLVM, probably doesn't work for anyone. Having a codebase that is 99% signed is much more feasible. The worst is a codebase with plenty of both, which will be guaranteed endless subtle bugs and/or a ton of casts. That's what they'll end up with.<p>Apparently the C++ committee agrees that size_t being unsigned was a huge mistake (reference needed), and I would agree.
Related discussion: <a href="https://github.com/ericniebler/stl2/issues/182" rel="nofollow">https://github.com/ericniebler/stl2/issues/182</a> <a href="https://github.com/fish-shell/fish-shell/issues/3493" rel="nofollow">https://github.com/fish-shell/fish-shell/issues/3493</a> <a href="https://wesmckinney.com/blog/avoid-unsigned-integers/" rel="nofollow">https://wesmckinney.com/blog/avoid-unsigned-integers/</a><p>Even LLVM has all this comical code dealing with negative values stored in unsigneds.<p>The idea that you should use unsigned to indicate that a value can't be negative is also pretty arbitrary. Your integer type doesn't represent the valid range of values in almost all cases, enforcing it is an unrelated concern.
Quick typo under OMG-CODEORG-2:<p><pre><code> #pragma once
#ifdef __cpluspus // <-- should be __cplusplus
extern "C" {
#endif
#include "api_types.h"
// ...
#ifdef __cplusplus
}
#endif
</code></pre>
Can't say I'm a fan of OMG-CODEORG-3, however, it sounds like compilation time is a key metric for them.. I prefer a John Lakos style "physical components" set up which emulates a type-as-module inclusion style. At least OMG-CODEORG-3 clearly states that include order becomes important as a result.
<i>I.e., use a double parameter that specifies seconds, instead of an uint32_t that specifies milliseconds.</i><p>This can have surprising and sometimes unpleasant consequences; see <a href="https://0.30000000000000004.com" rel="nofollow">https://0.30000000000000004.com</a>
the layout and typesetting on this looks good in Firefox 70!<p>view-source:<a href="https://ourmachinery.com/files/guidebook.md.html" rel="nofollow">https://ourmachinery.com/files/guidebook.md.html</a><p><meta charset="utf-8" emacsmode="-<i>- markdown -</i>-">
Objects as structs with function pointers? 1990 is calling. I'm not a huge C++ fan, but trying to emulate C++ concepts in C is kind of lame at this late date.
OMG-DESIGN-4: Explicit is better than implicit<p>Ahh, straight out of the zen of Python!<p><pre><code> $ python -c "import this"</code></pre>