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.
A format that is just as complex, and yet much easier to read is JSON which is typically the go-to config format in the Node.js community. That’s because JSON file format is essentially a subset of JavaScript language spec itself. As a result, every JSON file is actually valid JavaScript code (but not the other way around). You can slurp it up from disc, exec() it and have a live object. Granted, this is something you probably shouldn’t do security wise – there are much better method of serializing and deserializing JSON files – but it is a distinct possibility.
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.
In a way the JavaScript syntax thing is a double edged blade. It gives JSON a lot of power and flexibility, but makes the files very brittle. It is incredibly easy to “break” your config file by deleting the wrong line. This almost never happens with Java .properties files or Windows .ini files in which lines are self contained.
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.
I’m confused by the remark that “[YAML] is almost as flexible as JSON”. JSON is a subset of YAML. YAML should be more powerful and flexible.
I’m with you that XML is the worse of text configuration files. I prefer it over a binary-only config but I don’t have to like it! The worse offender is alternating normal form XML — i.e. Apache Maven style. It’s extra overly-verbose, even for XML.
Outside of specific Java build systems, fortunately there’s only one program I use that has an XML config that I bother to version control: Openbox (rc.xml). Everything else in my dotfiles repository generally follows a simple-types “key = value” paradigm: bash, ssh, VLC, GTK, Pentadactyl, s3cmd (ini), git (ini), quilt, reportbug, Xmodmap, and lxterminal (ini). My blog is configured using YAML.
As for having a favorite format, I don’t know if I can pick an overall favorite. I see config files as prime examples of domain-specific languages. The syntax and grammar should be powerful within the context of the system it’s configuring. Emacs is configured with s-expressions and YAML would be a poor fit, but using s-expressions as Jekyll front matter would be awkward.
I think you mean eval(). :-)
@ Athanor:
Hmm, I thought about this and I think neither is a subset of the other … but only barely so. JSON has null, but I think it’s the only thing JSON can express that YAML cannot. On the other hand, YAML has references, so it’s possible to express a circular or otherwise non-hierarchical data structure in YAML but not in JSON (or most other languages).
YAML numbers are also less specified than JSON, which follows the JavaScript specification. So YAML can potentially express an arbitrary precision while JSON is limited to double-precision floating point. However, in practice YAML will probably be under similar constraints, so I’m not counting this. It’s like when we call a programming language Turing-complete even though a Turing machine is impossible to build. A practical implementation will not be Turing-complete.
That’s a difficult question, because while I can easily name some terrible formats, it’s hard to choose my favorite; it really depends on the application. For example, I like how I can configure my WM (Awesome) using a Lua script, but it’d be completely inadequate for most software. Likewise, YAML is nice for more complex formats, but usually overkill, in my opinion.
I added “resolv.conf” because I think it’s the most readable configuration format I know, and I often use it for my own scripts. It doesn’t handle very complex settings, but I wager it’s good enough for 90% of well-designed programs.
If I were creating application, I would go with XML/json/properties/yml file depending on the language in use.
As user I have always liked the .cfg files in source/gold source engine. Its just list of commands, so its possible to do little scripts right in the config file:
bind DEL "toggle net_graph 0 3"bind PGUP "toggle_con"
cl_disablehtmlmotd 1
viewmodel_fov 70
fov_desired 90
Simple and easy to edit. Also, all the commands are the same as in the in-game console.
sendmail.cf?
But seriously, lisp/lua/tcl or a similar simple scripting language, for anything sufficiently advanced. And as some kind of variant of Greenspun’s Law, this happens pretty often. And if the syntax can’t cope, you’ll just end up with a bunch of stupid “DSLs” or people bending over backwards to write or apply preprocessors. Sometimes even m4!
Speaking of which, I did kinda like the X11 resources format, e.g. used in your .Xdefaults. And there you could actually use the C preprocessor…
Never been a big fan of YAML for some kind of reason (indenting & formatting, probably), but at least it’s more readable as config format than XML or JSON. I think TOML might be worth watching, too. Basically .ini++.
Chris Wellons wrote:
YAML does have nulls: http://yaml.org/type/null.html
@ IceBrain:
Yup, you’re right. I was going off of the Wikipedia article which makes no mention of null. Now that I know this I think JSON a subset of YAML.
I tend to prefer config file formats that are either executable, or have standard formats. When I used to a lot of Python coding, I tended to make my config files Python files. That way I could import configs just by importing the file and accessing its variables. Of course this is kinda untenable if you’re writing software to deploy, but I was doing personal projects or research projects with a small team.
Currently I’m doing a lot of work relating to graphs and I’m using the DOT language/format for representing them. That way I can serialize/import from a well-known format (and share easily) and make use of all the other tools for working with (in particular, visualizing) them.