Changes in CODING_STYLE http://src.iws.cs.ovgu.de/source/rss/systemd/CODING_STYLE en Copyright 2005 Java CODING_STYLE: make sure line break recommendation matches edit configuration In the .vimrc and .dir-locals.el we suggest a line width of 119. We should recommend the same in CODING_STYLE. /systemd/CODING_STYLE - 1c4e4227faa77026eeb633e2e575bedf1897daa3 Lennart Poettering <lennart@poettering.net> CODING_STYLE: elaborate on usage of C99 fixed size integer types /systemd/CODING_STYLE - fa195fa775e548a15c0cc21d4c8611fd0286245a Lennart Poettering <lennart@poettering.net> update CODING_STYLE /systemd/CODING_STYLE - ec566e4c7cee67ec2c39475ef08f18a9f1b80efd Lennart Poettering <lennart@poettering.net> update CODING_STYLE /systemd/CODING_STYLE - 041f793b6b1e4b86edc909b4b2867463b3ef3efd Lennart Poettering <lennart@poettering.net> update CODING_STYLE /systemd/CODING_STYLE - c7ddad5148de6e41445f62a80fb6846dce1a6856 Lennart Poettering <lennart@poettering.net> update CODING_STYLE with various additions /systemd/CODING_STYLE - 8ac5aaa9fa47622e480391886c34f052f5ff909d Lennart Poettering <lennart@poettering.net> tree-wide: never use the off_t unless glibc makes us use it off_t is a really weird type as it is usually 64bit these days (at least in sane programs), but could theoretically be 32bit. We don't support off_t as 32bit builds though, but still constantly deal with safely converting from off_t to other types and back for no point. Hence, never use the type anymore. Always use uint64_t instead. This has various benefits, including that we can expose these values directly as D-Bus properties, and also that the values parse the same in all cases. /systemd/CODING_STYLE - 59f448cf15f94bc5ebfd5b254de6f2441d02fbec Lennart Poettering <lennart@poettering.net> CODING_STYLE: mandate alphabetical include order systemd-internal headers must not rely on include order. That means, they either must contain forward-declarations of used types/functions, or they must include all dependencies on their own. Therefore, there is no reason to mandate an include order on the call-side. However, global includes should always be ordered first. We don't want local definitions to leak into global includes, possible changing their behavior. Apparently, namespacing is a complex problem that people are incapable of implementing properly.. Apart from "global before local", there is no reason to mandate a random include order (which we happen to do right now). Instead, mandate alphabetical ordering. The current rules do not have any benefit at all. They neither reduce include-complexity, nor allow easy auditing of include files. But with alphabetical ordering, we get duplicate-detection for free, it gets *much much* easier to figure out whether a header is already included, and it is trivial to add new headers. /systemd/CODING_STYLE - 54c1f2d761b506132a709a7e8573c7b54d048cf0 David Herrmann <dh.herrmann@gmail.com> CODING_STYLE: say that "for (;;)" is better than "while (1)" /systemd/CODING_STYLE - cad6982291a0e3cae4b8b1fad140ffd512e2835c Lennart Poettering <lennart@poettering.net> Stop talking about the "XDG" version of basename() XDG refers to X Desktop Group, a former name for freedesktop.org. This group is responsible for specifications like basedirs, .desktop files and icon naming, but as far as I know, it has never tried to redefine basename(). I think these references were meant to say XPG (X/Open Portability Guide), a precursor of POSIX. POSIX is better-known and less easily confused with XDG, and is how the basename(3) man page describes the libgen.h version of basename(). The other version of basename() is glibc-specific and is described in basename(3) as "the GNU version"; specifically mention that version, to disambiguate. /systemd/CODING_STYLE - 11c9f1e48a683fb2e78ee531016099d567baa19a Simon McVittie <simon.mcvittie@collabora.co.uk> CODING_STYLE: document order in which to #include headers /systemd/CODING_STYLE - 1811232c4cc5d93cb02d93ed448a712e88e30868 Lennart Poettering <lennart@poettering.net> CODING_STYLE: document that we should avoid kernel types like u32 /systemd/CODING_STYLE - 8cb1cc8dc339be9f96cd290882d775cccfc4d7e7 Lennart Poettering <lennart@poettering.net> CODING_STYLE: document that EXIT_FAILURE and EXIT_SUCCESS should be used /systemd/CODING_STYLE - 0fef704c6fbb07cb0289eadc405f49286aa70e53 Lennart Poettering <lennart@poettering.net> CODING_STYLE: document best practices when initializing structs /systemd/CODING_STYLE - a5ecb0cec25befafdee1e32c6f24cda8e29f89af Lennart Poettering <lennart@poettering.net> CODING_STYLE: document alloca() DONTS /systemd/CODING_STYLE - 42706f47c918b035dee82f4bad15bf6499592d1c Lennart Poettering <lennart@poettering.net> CODING_STYLE: document that we prefer /* comments */ over // comments /systemd/CODING_STYLE - 2708526c4ade0473b95f6c93d21f6d516b89a924 Lennart Poettering <lennart@poettering.net> CODING_STYLE: document how destructors should work /systemd/CODING_STYLE - ba780c116fc919c58fad07f45f4e800a062af63e Lennart Poettering <lennart@poettering.net> CODING_STYLE: mention that dup() should not be used /systemd/CODING_STYLE - 9ff3e22aa93fe461f8971f2468c65dc928fadc9e Lennart Poettering <lennart@poettering.net> CODING_STYLE: clarify that exit() is never OK to call /systemd/CODING_STYLE - 3dbafa39b08025350e7b17f4874a343c789ff9b3 Lennart Poettering <lennart@poettering.net> CODING_STYLE: mention casting of function invocations to (void) /systemd/CODING_STYLE - 918315e457ca36cab94ff3b6060e143968c99ace Lennart Poettering <lennart@poettering.net>