Very frequently applications you write will need config files. Sometimes said files are going to be used to internally preserve the state of the application and only read or written to by the app itself, never being exposed to the user. In such case they can be just raw binary data dumps or serialized objects. More frequently however you may want to give user the ability to view or edit said files by hand. This could either be used as a back-up (for example if the user is for some reason unable to launch the UI) or as primary method of configuration.
When you decide to sit down and use a human readable config file, you typically want to settle down on one of the already established formats. There are quite a few of them and all have their pros and cons. How do you pick the right one?
Well, sometimes you don’t. Sometimes the environment you are working in is going to dictate the way your config files are going to look. For example if you are using Java then you’re probably going to use the java.util.Properties class which is a specialized hash table with methods that lets you dump its contents to disk as a line based .properties file. If you are using .NET then you probably will be making use of the System.Configuration class which generates XML files instead. When your environment provides appropriate tooling and standard file formats, there is really no reason to deviate unless said standard is inadequate for your purposes.
That said, not all config file formats are created equal. For example, I absolutely hate XML configs. Especially ones that are simple key-value pair collections with no complexity whatsoever. XML can be really powerful for data storage because in essence it is a textual representation of a traversable tree. The XML tags are nodes which have very explicit parent-child relationships, and the entire file has a strong hierarchical structure to it. This makes it really great for storing data that is inherently hierarchical in nature. The problem is that configuration files typically aren’t. Most config files are actually much better represented as a hash table, which can be serialized in a much simpler way than a hierarchical node list, and is much easier to search than a tree. As a result XML config files are neither human nor machine friendly. Humans have to waddle through the sea of redundant tags and a machine has to build and traverse a tree when it could just as well be working with a hash table.
JSON can be used to build complex data structures. It can yield a deeply nested, hierarchical structure akin to an XML tree, or act as a simple, flat hash table. Combine it with a succinct, clean syntax and you have something that is almost perfect for all occasions. Except for all those times when you leave a trailing comma or forget a bracket and the whole thing blows up.
Personally, I think YAML is probably the best config file format out there as of yet. It combines the simplicity of .properties or .ini files (simplest YAML file is just a list of colon separated key-value pairs and nothing else) with the ability to represent more complex data structures. It is almost as flexible as JSON when it comes to arranging data in hierarchical relationships, but its syntax is much simpler and less restrictive. As a result files are more robust and less prone to breaking when edited manually by hand.
So which is your favorite and why? If you add another file format to the poll, please let us know more about it in the comments – as in where it is used, how it works and etc.