From 35840a3e789dd67528caefc146deb698bd6ac7a5 Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Tue, 27 Jan 2015 12:26:03 -0800 Subject: CodingGuidelines: describe naming rules for configuration variables 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 --- Documentation/CodingGuidelines | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation/CodingGuidelines') diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 894546dd75..0f8cccf52d 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -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..description does. + + Writing Documentation: Most (if not all) of the documentation pages are written in the -- cgit v1.2.3