Re: [PATCH 3/3] CodingGuidelines: describe naming rules for configuration variables

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> You make an interesting point: values that start as a list of
> independent booleans can grow dependencies over time.
>
> In retrospect, ISTM that a better interface for the indentation-related
> "whitespace" settings would have been something like
>
> * "whitespace.indent" -- a single value chosen from "tabs-only |
> spaces-only | tabs-when-possible | anything"
> * "whitespace.tabwidth" -- an integer value
>
> This would have made the mutual-exclusivity of those choices manifest in
> the style of configuration rather than hoping that the user notices that
> his settings contradict each other.
>
> Let's dig into this example some more by imagining some other
> hypothetical future extensions.

Let's not; that line of thought entirely misses the point.  If you
start from one set of variables, you can define a structure
(e.g. "there are indentation-related and you must choose only one
among them") over it after the fact.

Once you have chosen a structure, you have to live with it.  Either
you make sure that a structure itself is extensible, or you make
sure you accept a new variable only if it fits within a structure.
Either way, you lose.  You cannot predict the future, and you do not
want to constrain those who will contribute to the project in the
future.

My aversion to one-variable-per-knob was primarily against the
"because that is how the variables are internally represented; a
collection of enums that can be independently set" argument.  If we
assume that one-variable-per-knob style implies variables that can
be independently set, that _is_ defining the structure the future
work has to live within.

But as I and Peff discussed in the other sub(sub)thread, having two
variables placed flatly in the namespace, e.g. ws.indentWithTab and
ws.noTabInIndent, does not have to mean they are independent.

And the opposite is also true; having these two knobs as possible
elements of the value of a single variable does not imply they
always have meaningful interactions.

So I am fine with "fsck.missingTagger = ignore/warn/error", as long
as the argument that supports the style is not "because
fsck.missingTagger and fsck.malformedIdent are independent".