]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - CODING_STYLE
cgroup: fix handling of TasksAccounting= property
[thirdparty/systemd.git] / CODING_STYLE
index ed61ea9d28169d4d4f9fffbc9f1898314c4e6cb9..ae818126cb92218f0508da598a2410a36ec8c9dd 100644 (file)
@@ -1,9 +1,11 @@
 - 8ch indent, no tabs, except for files in man/ which are 2ch indent,
   and still no tabs
 
-- We prefer /* comments */ over // comments, please. This is not C++, after
-  all. (Yes we know that C99 supports both kinds of comments, but still,
-  please!)
+- We prefer /* comments */ over // comments in code you commit, please. This
+  way // comments are left for developers to use for local, temporary
+  commenting of code for debug purposes (i.e. uncommittable stuff), making such
+  comments easily discernable from explanatory, documenting code comments
+  (i.e. committable stuff).
 
 - Don't break code lines too eagerly. We do *not* force line breaks at
   80ch, all of today's screens should be much larger than that. But
 - We never use the POSIX version of basename() (which glibc defines it in
   libgen.h), only the GNU version (which glibc defines in string.h).
   The only reason to include libgen.h is because dirname()
-  is needed. Everytime you need that please immediately undefine
+  is needed. Every time you need that please immediately undefine
   basename(), and add a comment about it, so that no code ever ends up
   using the POSIX version!
 
   proper event, instead of doing time-based poll loops.
 
 - To determine the length of a constant string "foo", don't bother
-  with sizeof("foo")-1, please use strlen("foo") directly. gcc knows
-  strlen() anyway and turns it into a constant expression if possible.
+  with sizeof("foo")-1, please use STRLEN() instead.
 
 - If you want to concatenate two or more strings, consider using
   strjoin() rather than asprintf(), as the latter is a lot
   global variables. Why are global variables bad? They usually hinder
   generic reusability of code (since they break in threaded programs,
   and usually would require locking there), and as the code using them
-  has side-effects make programs intransparent. That said, there are
+  has side-effects make programs non-transparent. That said, there are
   many cases where they explicitly make a lot of sense, and are OK to
   use. For example, the log level and target in log.c is stored in a
   global variable, and that's OK and probably expected by most. Also
 
 - When exposing public C APIs, be careful what function parameters you make
   "const". For example, a parameter taking a context object should probably not
-  be "const", even if you are writing an other-wise read-only accessor function
+  be "const", even if you are writing an otherwise read-only accessor function
   for it. The reason is that making it "const" fixates the contract that your
   call won't alter the object ever, as part of the API. However, that's often
   quite a promise, given that this even prohibits object-internal caching or
 
 - Make sure to enforce limits on every user controllable resource. If the user
   can allocate resources in your code, your code must enforce some form of
-  limits after which it will refuse operation. It's fine if it is hardcoded (at
+  limits after which it will refuse operation. It's fine if it is hard-coded (at
   least initially), but it needs to be there. This is particularly important
   for objects that unprivileged users may allocate, but also matters for
   everything else any user may allocated.
 
 - htonl()/ntohl() and htons()/ntohs() are weird. Please use htobe32() and
   htobe16() instead, it's much more descriptive, and actually says what really
-  is happening, after all htonl() and htons() don't operation on longs and
+  is happening, after all htonl() and htons() don't operate on longs and
   shorts as their name would suggest, but on uint32_t and uint16_t. Also,
   "network byte order" is just a weird name for "big endian", hence we might
   want to call it "big endian" right-away.
   that interrupted system calls are automatically restarted, and we minimize
   hassles with handling EINTR (in particular as EINTR handling is pretty broken
   on Linux).
+
+- When applying C-style unescaping as well as specifier expansion on the same
+  string, always apply the C-style unescaping fist, followed by the specifier
+  expansion. When doing the reverse, make sure to escape '%' in specifier-style
+  first (i.e. '%' → '%%'), and then do C-style escaping where necessary.