Re: Best practices for configuration files

RickardL said:

Hi,

I am wondering if anyone has an idea of what the best practices are
for configuration files. Let me elaborate.

Say you have this program that you are developing and you would like
its behavior to be customizable by the user. You decide to use a
configuration file that lets the users specify some variables that
will alter the behavior of your program.

But there has to be some default values, right?

Right.

If the user deletes
the configuration file, we wouldn't want the program to crash, right?

Right.

So the defaults should be hard coded into the program?

Right.

Then if unknown parameters are encountered while parsing the
configuration file, how do you deal with that?

<shrug> Make it very easy to check that this really is one of your
configuration files! For example, you might start the file off with:

%RSI19741203P1643V318

where % is a throwaway (e.g. a comment marker), RSI is your organisation's
name (yeah, it stands for Rickardl Software Inc, but obviously you plug in
whatever you like), then comes your birthdate (whatever), then the program
ID, and then the version ID for that program.

If all that stuff matches up to what your program is expecting (*except*
the version number), you can be reasonably sure that the config file isn't
accidentally from some other program completely, right? So either it's
been accidentally screwed up or it's been deliberately screwed up, but
either way at least you know it's yours.

Now, the trick here is to know what version of the program the config file
claims to work with.

If it claims to work with *your* version (the current version that is
running, I mean), then you know you have a corrupt file. Maybe you (by
which of course I mean your program) read it as best you can to get what
you can from it, but you should rewrite it without the corruption at your
earliest opportunity. (Tell the user you're doing this, and give him the
chance to stop you. Remember - it's *his* filesystem, not yours.)

If it claims to work with a *prior* version, maybe it isn't corrupt after
all. Maybe you dropped support for a setting. The trick here is to
maintain support for files created with older versions of your software.
Most mainstream applications do this.

If it claims to work with a *future* version, then keep your hands off at
all costs. If you write code to "step around" stuff you don't understand
(because you're future-proofing your "future you" who does understand that
stuff and who added the stuff that the "now you" doesn't understand yet),
that's fine PROVIDED that you remember doing this when you become "future
you", and keep your config-handling clean enough that older versions of
your software /can/ step around the changes you make without breaking
anything.

Bottom line: keep your config design as clean as possible!

And do try not to abort the program on detecting bad config unless you
really have no other choice.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: RESTART and LOAD CONFIGURATION FILE help
    ... > After 2 hours with DELL trying to get an Axim to talk to an Inspiron, ... > The status bar configuration file is corrupt ... > Corel has encountered a problem and needs to close.....etc. ...
    (microsoft.public.windowsxp.general)
  • Re: RESTART and LOAD CONFIGURATION FILE help
    ... >> assorted problems, the only problems I can not fix are the following. ... >> The status bar configuration file is corrupt ... >> Need Help on This One, Bill ...
    (microsoft.public.windowsxp.general)
  • Error 800703F1
    ... error msge tells me that the configuration file is corrupt. ... to fix? ... i'm using windows me ...
    (microsoft.public.windowsmedia.player)