]> git.ipfire.org Git - thirdparty/systemd.git/commitdiff
CODING_STYLE: split out section about command line parsing
authorLennart Poettering <lennart@poettering.net>
Fri, 12 Apr 2019 14:40:34 +0000 (16:40 +0200)
committerLennart Poettering <lennart@poettering.net>
Fri, 12 Apr 2019 14:40:34 +0000 (16:40 +0200)
docs/CODING_STYLE.md

index 20f9e10e7a38dd24be56a99739896adcb25a59e2..2809213af5c77308a222928f71556e5c97befd89 100644 (file)
@@ -161,11 +161,6 @@ title: Coding Style
   `is_main_thread()` to detect whether the calling thread is the main
   thread.
 
-- Command line option parsing:
-  - Do not print full `help()` on error, be specific about the error.
-  - Do not print messages to stdout on error.
-  - Do not POSIX_ME_HARDER unless necessary, i.e. avoid `+` in option string.
-
 - Do not write functions that clobber call-by-reference variables on
   failure. Use temporary variables for these cases and change the
   passed in variables only on success.
@@ -261,13 +256,6 @@ title: Coding Style
   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.
-
 - 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 otherwise read-only accessor function
@@ -469,6 +457,19 @@ title: Coding Style
   effect on the regular file. If in doubt consider turning off `O_NONBLOCK`
   again after opening.
 
+## Command Line
+
+- 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.
+
+- Command line option parsing:
+  - Do not print full `help()` on error, be specific about the error.
+  - Do not print messages to stdout on error.
+  - Do not POSIX_ME_HARDER unless necessary, i.e. avoid `+` in option string.
+
 ## Referencing Concepts
 
 - When referring to a configuration file option in the documentation and such,