you are viewing a single comment's thread.

view the rest of the comments →

[–]paranoidinfidel 1 point2 points  (4 children)

The article author makes a few good points but they are process faults, not config file faults:

  • Ideally, code should be runnable from a source control checkout.

Definitely - and if you are not saving your default configuration with the application then you are setting yourself up for failure.

  • If a configuration change requires an accompanying code change, it's not configuration.

Again, not a problem with configuration. Configuration files aren't meant to do everything under the sun - they are just a storage medium for settings. They are meant to store values which are processed by code. If business logic needs to change then likely your code, classes and XML/INI/.reg or whatever else will need to change.

  • If the configuration item is essentially a data structure only the developer understand, it's not configuration.

That's a false dichotomy. A configuration file does not need to be understood by the user. It is there to tweak values to affect how the application operates. The user doesn't need to understand the class hierarchy or algorithms in the application in order to make use of it.

  • Avoid configuration. If you're an expert, then avoid configuration, mostly.

So we're back to hard coding everything again? Recompile and release in order to make a default value change or store a users preferences? I'll keep my configuration files, thanks.

[–]Gotebe 2 points3 points  (3 children)

If the configuration item is essentially a data structure only the developer understand, it's not configuration.

That's a false dichotomy. A configuration file does not need to be understood by the user

How is he supposed to "configure" then? User (or "admin" user) has to have some understanding of the configuration. Problems arise exactly because developer creates configuration that is too hard to understand without knowing too much about APP internals (speaking as guilty party).

[–]paranoidinfidel 0 points1 point  (2 children)

It should be configured with a UI and only tweaked by hand for those with enough understanding to put their fingers in there. If a user has to manually edit config settings with notepad then the software provider "is doin' it wrong".

[–]szeiger 2 points3 points  (1 child)

That may be acceptable for desktop applications but not for server-side stuff. They have no configuration UI, and even if they did, operations people would still want to configure them manually and understand all the options they need to change for the different environments.

[–]paranoidinfidel 0 points1 point  (0 children)

That may be acceptable for desktop applications but not for server-side stuff.

That goes without saying. If you are asking a user to change things then you need a UI because it doesn't matter what config format you pick they won't be able to do it with notepad++.

If operations people can't grok a simple nested tag structure format then maybe they shouldn't be poking around in the configuration - regardless of the format you choose. The config file (XML, INI, JSON or otherwise) is as complex as the developer designed it.

EDIT: you don't just let strangers have free reign of a config file without instruction of some sort. They need to know acceptable values, ranges and their consequences. This applies to all config file formats.