CODING_STYLE: split out section about command line parsing
This commit is contained in:
parent
b065e1f176
commit
996f119d97
|
@ -161,11 +161,6 @@ title: Coding Style
|
||||||
`is_main_thread()` to detect whether the calling thread is the main
|
`is_main_thread()` to detect whether the calling thread is the main
|
||||||
thread.
|
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
|
- Do not write functions that clobber call-by-reference variables on
|
||||||
failure. Use temporary variables for these cases and change the
|
failure. Use temporary variables for these cases and change the
|
||||||
passed in variables only on success.
|
passed in variables only on success.
|
||||||
|
@ -261,13 +256,6 @@ title: Coding Style
|
||||||
global variables, for example data parsed from command lines, see
|
global variables, for example data parsed from command lines, see
|
||||||
below.
|
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
|
- When exposing public C APIs, be careful what function parameters you make
|
||||||
`const`. For example, a parameter taking a context object should probably not
|
`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
|
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`
|
effect on the regular file. If in doubt consider turning off `O_NONBLOCK`
|
||||||
again after opening.
|
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
|
## Referencing Concepts
|
||||||
|
|
||||||
- When referring to a configuration file option in the documentation and such,
|
- When referring to a configuration file option in the documentation and such,
|
||||||
|
|
Loading…
Reference in a new issue