Re: [extremeprogramming] About placing configuration defaults

not very related, but interesting: https://www.lucidchart.com/techblog/2018/07/16/why-json-isnt-a-good-configuration-language/ 
I don’t buy the arguments, or the necessity of commenting things out for different uses (preferring to point an env var to a different file/dir) but found it interesting nonetheless.



Sent from Yahoo Mail for iPad


On Tuesday, November 19, 2019, 2:21 PM, Avi Kessner <[email protected]> wrote:

Because it's easier to read, maintain, and develop.
When all your defaults are defined at the top level it's hard to reason about the more dynamic configurations which don't have many function calls.  It's much better to make the function call with a clear default parameter.If you define all the defaults at the point of use, it becomes annoying and distracting to keep defining a common base url which could have just been defined at the top of the heirarchy. 
It's possible I missunderstood the original question, but my understanding was that it was being asked if one should have a single class with all the default values defined, or if the default should be passed in when requesting the current configuration value.For a horrible example of the two options:1.  Configs.get(key, defaultValue)
2.  Configs.getKey = function ( ) {  return env.key || defaultValue}
On Tue, Nov 19, 2019, 21:41 Steve Gordon <[email protected]> wrote:

It would never occur to me to organize the defaults differently than I would organize the editable configurations.  Why would I want to impose a different structure on the programmers and the maintainers, unless the maintainers were going to use an interface such as a rules engine)
On Tue, Nov 19, 2019 at 12:10 PM Avi Kessner <[email protected]> wrote:

Only programmers working on the code need to know where defaults are stored.I understood the question to be about the defaults, i.e. no value is set, rather than about the location of the configuration data itself.
On Tue, Nov 19, 2019, 18:35 Steve Gordon <[email protected]> wrote:

Avi,
Should we really require the customer to have enough insight into the internal object architecture of the software to be able to guess where a particular configuration choice is stored?
On Tue, Nov 19, 2019 at 8:25 AM Avi Kessner <[email protected]> wrote:

My understanding is that the defaults should be placed closest to where these things change.

Some defaults should be at the top level, especially defaults related to the environment. (base urls, api keys etc)
Some defaults should be placed where the configuration is being requested, especially arguments that are passed in at runtime. (test file name, number of interactions, other optional args you might have)
Wherever someone might be interested in what the default is, try to have them searching for it as little as possible.

The less often the value of the config is likely to change, the "higher up", I think it should be.

brought to you by the letters A, V, and I
and the number 47

_._,_
















-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#160242): https://groups.io/g/extremeprogramming/message/160242
Mute This Topic: https://groups.io/mt/60557252/2417047
Group Owner: [email protected]
Unsubscribe: https://groups.io/g/extremeprogramming/leave/4902963/619838065/xyzzy  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-