CodingGuidelines: describe naming rules for configuration variables
authorJunio C Hamano <gitster@pobox.com>
Tue, 27 Jan 2015 20:26:03 +0000 (12:26 -0800)
committerJunio C Hamano <gitster@pobox.com>
Mon, 2 Feb 2015 19:28:55 +0000 (11:28 -0800)
We may want to say something about command line option names in the
new section as well, but for now, let's make sure everybody is clear
on how to structure and name their configuration variables.

The text for the rules are partly taken from the log message of
Jonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for
add.ignore-errors, 2010-12-01).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/CodingGuidelines
index 894546dd75416fcf09542096a67b2f22a7d0de7a..0f8cccf52da4882377a56042a4de3ff754d357b9 100644 (file)
@@ -413,6 +413,29 @@ Error Messages
  - Say what the error is first ("cannot open %s", not "%s: cannot open")
 
 
+Externally Visible Names
+
+ - For configuration variable names, follow the existing convention:
+
+   . The section name indicates the affected subsystem.
+
+   . The subsection name, if any, indicates which of an unbounded set
+     of things to set the value for.
+
+   . The variable name describes the effect of tweaking this knob.
+
+   The section and variable names that consist of multiple words are
+   formed by concatenating the words without punctuations (e.g. `-`),
+   and are broken using bumpyCaps in documentation as a hint to the
+   reader.
+
+   When choosing the variable namespace, do not use variable name for
+   specifying possibly unbounded set of things, most notably anything
+   an end user can freely come up with (e.g. branch names).  Instead,
+   use subsection names or variable values, like the existing variable
+   branch.<name>.description does.
+
+
 Writing Documentation:
 
  Most (if not all) of the documentation pages are written in the