+
+- When you define a destructor or unref() call for an object, please
+ accept a NULL object and simply treat this as NOP. This is similar
+ to how libc free() works, which accepts NULL pointers and becomes a
+ NOP for them. By following this scheme a lot of if checks can be
+ removed before invoking your destructor, which makes the code
+ substantially more readable and robust.
+
+- Related to this: when you define a destructor or unref() call for an
+ object, please make it return the same type it takes and always
+ return NULL from it. This allows writing code like this:
+
+ p = foobar_unref(p);
+
+ which will always work regardless if p is initialized or not, and
+ guarantees that p is NULL afterwards, all in just one line.
+
+- Use alloca(), but never forget that it is not OK to invoke alloca()
+ within a loop or within function call parameters. alloca() memory is
+ released at the end of a function, and not at the end of a {}
+ block. Thus, if you invoke it in a loop, you keep increasing the
+ stack pointer without ever releasing memory again. (VLAs have better
+ behaviour in this case, so consider using them as an alternative.)
+ Regarding not using alloca() within function parameters, see the
+ BUGS section of the alloca(3) man page.
+
+- Use memzero() or even better zero() instead of memset(..., 0, ...)
+
+- Instead of using memzero()/memset() to initialize structs allocated
+ on the stack, please try to use c99 structure initializers. It's
+ short, prettier and actually even faster at execution. Hence:
+
+ struct foobar t = {
+ .foo = 7,
+ .bar = "bazz",
+ };
+
+ instead of:
+
+ struct foobar t;
+ zero(t);
+ t.foo = 7;
+ t.bar = "bazz";
+
+- When returning a return code from main(), please preferably use
+ EXIT_FAILURE and EXIT_SUCCESS as defined by libc.
+
+- The order in which header files are included doesn't matter too
+ much. However, please try to include the headers of external
+ libraries first (these are all headers enclosed in <>), followed by
+ the headers of our own public headers (these are all headers
+ starting with "sd-"), internal utility libraries from src/shared/,
+ followed by the headers of the specific component. Or in other
+ words:
+
+ #include <stdio.h>
+ #include "sd-daemon.h"
+ #include "util.h"
+ #include "frobnicator.h"
+
+ Where stdio.h is a public glibc API, sd-daemon.h is a public API of
+ our own, util.h is a utility library header from src/shared, and
+ frobnicator.h is an placeholder name for any systemd component. The
+ benefit of following this ordering is that more local definitions
+ are always defined after more global ones. Thus, our local
+ definitions will never "leak" into the global header files, possibly
+ altering their effect due to #ifdeffery.