summaryrefslogtreecommitdiff
path: root/CODING_STYLE
diff options
context:
space:
mode:
Diffstat (limited to 'CODING_STYLE')
-rw-r--r--CODING_STYLE26
1 files changed, 26 insertions, 0 deletions
diff --git a/CODING_STYLE b/CODING_STYLE
index d373f4dea3..8b945cd3c1 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -346,3 +346,29 @@
- 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.