journald-server: port to extract_first_word

[thirdparty/systemd.git] / CODING_STYLE

diff --git a/CODING_STYLE b/CODING_STYLE
index cf86de5f622f9c84a81b12ddc6d20c28da5f8328..8b945cd3c10a9d4bbaa76553df83b351e4790fe2 100644 (file)
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -332,9 +332,43 @@
 - Avoid leaving long-running child processes around, i.e. fork()s that
   are not followed quickly by an execv() in the child. Resource
   management is unclear in this case, and memory CoW will result in
-  penalties in the parent much much later on.
+  unexpected penalties in the parent much much later on.
 
 - Don't block execution for arbitrary amounts of time using usleep()
   or a similar call, unless you really know what you do. Just "giving
   something some time", or so is a lazy excuse. Always wait for the
   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.
+
+- If you want to concatenate two or more strings, consider using
+  strjoin() rather than asprintf(), as the latter is a lot
+  slower. This matters particularly in inner loops.
+
+- Please avoid using global variables as much as you can. And if you
+  do use them make sure they are static at least, instead of
+  exported. Especially in library-like code it is important to avoid
+  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
+  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
+  in many cases we cache data in global variables. If you add more
+  caches like this, please be careful however, and think about
+  threading. Only use static variables if you are sure that
+  thread-safety doesn't matter in your case. Alternatively consider
+  using TLS, which is pretty easy to use with gcc's "thread_local"
+  concept. It's also OK to store data that is inherently global in
+  global variables, for example data parsed from command lines, see
+  below.
+
+- If you parse a command line, and want to store the parsed parameters
+  in global variables, please consider prefixing their names with
+  "arg_". We have been following this naming rule in most of our
+  tools, and we should continue to do so, as it makes it easy to
+  identify command line parameter variables, and makes it clear why it
+  is OK that they are global variables.