96

Using a scripting language in place of a config file looks great at first glance: you have the full power of that language available and can simply eval() or import it. In practice, there are a few gotchas: it is a programming language, which needs to be learnt. To edit the config, you need to know this language sufficiently well. Configuration files ...


51

+1 to everything in amon's answer. I'd like to add this: You'll regret using Python code as your configuration language the first time you want to import the same configuration from within code written in a different language. For example if code that's part of your project and it written in C++ or Ruby or something else needs to pull in the configuration, ...


46

The same question arises in most of the projects I work on. Usually, I do this: If the set of possible values is unlikely to change any time soon, I use class/interface constants or enums in the code and enumerable fields in the database. Example: state of publishing of blog entries: 'not published', 'under moderation', 'published', etc. Values will ...


23

That would be super obnoxious. You: Wouldn't be able to see them all at once Wouldn't be able to place comments explaining why things are set the way they are Wouldn't be able to have documentation on what commands do, or what possible options are right in the configuration It would make backing up/version controlling your configs more obnoxious. Using a ...


22

The other answers are already very good, I'll just bring my experience of real-world usage in a few projects. Pros They are mostly already spelled out: if you are in a Python program, parsing is a breeze (eval); it works automatically even for more complex data types (in our program, we have geometric points and transformations, which are dumped/loaded ...


17

INI files have the disadvantage that they can't elegantly represent complex data structures like arrays. Therefore they are only useful for very simple configuration. Using a PHP file for configuration can be viewed as a security problem: Any code might be entered there. Worse, a simple syntax error like forgetting a closing quote could render the whole ...


16

Possibly there is no one good answer to this. It seems that you need to store this data somewhere safe, as it will be needed for disaster recovery purposes one day. This applies equally to properties files and scripts that set environment variables. With the source code (in SVN/GIT etc) is a really bad idea, as this data will contain production database ...


14

As a user, I don't expect the whitespace on either side of the equals sign to change the value of the key or the value. See this related question on unix.SE as too how confusing the situation can be. Don't make it harder on your users, trim whitespace from both the key and the value. If leading whitespace has a real use case for either, then let the user ...


12

I think YAML is best fit for your case. To my understanding, YAML is the de facto standard format for configuration files that need to be edited by hand. Many programming languages have a library for reading and/or writing YAML. JSON is closely related to YAML, but is little bit less easier to write than YAML, and is used more for communication between web ...


12

It's a fine goal to want your validation logic exist in only one place. It's not fine to take that as an excuse to give the user a lousy experience. You shouldn't "refuse the dialog to be closed". You should refuse to accept the submission. If the user wants to hit cancel let them. Wherever you put your validation code just use it as the user ...


12

Do not use bare strings to record URIs. Most languages have a type for them that handles joining absolute and relative paths automatically, ensuring you never need to sorry about doubled (or missing) slashes. Using this type will save you no end of problems,


11

It's up to you to define the rules for your app. For instance, you may define that: Whitespace before or after the equality sign is ignored, Whitespace inside the key is forbidden, Whitespace inside the value can be used only if the value is enclosed in quotes, so: say-hello = Hello, World! is forbidden, while: say-hello = "Hello, World!" is allowed, ...


11

It seems to me that the simplest solution is to make your version header unambiguous and make sure that the old format can never look like it has a format header, you simply look for it. If it's not there you assume it's the old style and try to find it from the middle. There might also be things in the beginning of the old format that can clue you in. ...


10

When there are a lot of sub-classes of a class which don't differ at all in their behavior (method implementations) and only differ in their values, it is often a good idea to represent them all with one class and read their previously hard-coded values from a configuration file, database table or other data source. To add a new sensor type, you would then ...


9

There are two extremes: Hard-code everything. This has the advantage of being easy and avoids the overhead of configuration. The disadvantages are obvious: maintainability, hot-deploying config changes, varying settings across environments, etc. Make everything a configuration setting. This has the most flexibility at the cost of having large ...


9

In my opinion, the nicest way for Exception handling in C# is the same exposed in this article: http://johannesbrodwall.com/2014/02/07/c-tricks-slimming-down-your-controllers/ (look for "Exception handling") Please note that the same pattern can be used for Java: http://johannesbrodwall.com/2013/09/25/offensive-programming/ The most important concept is: ...


9

In examining problems and possible solutions, it helps me to use a method popularized by Jeff Atwood: If God were to create a way to store sensitive configuration information, how would he do it? Well, he would know who needs configuration information and only give it to those people, and the information would never be able to be accessed by anyone else. ...


9

Most likely, you want a separate file. App.config is for application configuration, whereas what you are specifying is data. Your data store could eventually become a database or json, or whatever else. Keeping it separate will make moving to something else easier in the future.


9

I don't agree that storing settings in a database table is a bad separation of concerns. Your "concerns" will be separated by not defining a relationship between the settings table and other tables in your database. This is fine. The main thing to consider is how you expect the administrator of your system to make changes to the settings. It's much easier ...


9

Your old format starts with an 8-byte "size" element (probably a 64-bit long). If that's the file size in bytes (what I guess), it most probably never exceeded 100 GByte, meaning 2^37. So, if you offset your new version numbers by e.g. 2^40 and store them as the first 8 bytes, it'll be easy to discriminate: Read the first 64-bit word as "version". Version ...


9

Both is not really great. The first version is slightly better, because it at least attempts to be able to inject something. The problem is, strings cannot be injected based on the name of the parameter (at least none of the standard frameworks does this and although theoretically possible, nobody in their right mind would try that). You need a type to ...


8

The "means for them to use their own modified version of the library" in this context is letting users use their own libconfig.dll instead of yours if they want. By making it dynamically linked you have fulfilled this requirement. They can just replace the file. If you had made it statically linked instead, where you don't need the libconfig.dll in order ...


8

If your data will be in a database, i'd recommend having a table of 'light_types' in the same DB. This gives you the ability to use foreign keys to enforce a constraint that light->type can only be one of those values, so even if the code messes up, the data in the DB will always be valid. If the data won't be stored in a DB, creating one just for a bunch ...


8

This is a perfectly fine way of representing tree-shaped data. A file system is a tree database, why re-implement one on top of it? The most well-known implementation of this idea is the Windows Registry. Its main flaw is that it implements a filesystem alongside the filesystem and doesn't support the filesystem API, which means you can't use filesystem ...


8

Always including a trailing slash on the base URL and omitting the leading slash on the relative URL would allow you to concatenate the two in a manner that matches the spec on combining a base URL with relative URL to derive a full URL (RFC1808, Section 4). Doing it this way would allow you to have a consistent method that is also the least surprising.


8

The main question is: do you want your configuration file to be in some Turing complete language (like Python is)? If you do want that, you might also consider embedding some other (Turing complete) scripting language like Guile or Lua (because there could be perceived as "simpler" to use, or to embed, than Python is; read the chapter on Extending & ...


7

What we've come up with is the following. We only place one config file under version control. It contains the settings of the development environment. It serves two purposes. One, if a developer opens a project and runs it, it should just work (see also the Joel test :)). Two, it serves as a template only. You shouldn't actually store actual configuration ...


7

The first thing to do is to move to version control without modifying anything. Just get the files in there. If you discover any breakage later you can still retry. Enforce a "lock" on the sources until you reach step 4. Convert everything to a non-binary format. In the case of Excel you should be able to convert to OOXML, or you could go for a simpler ...


7

As long as all your configuration options come from a file, using interfaces does not bring you any benefit, since your configuration file can only provide fixed values. Even if you have to deal with more than one option per service, I do not see any convincing reason for using interfaces. You can still utilize simple "data objects" for the configuration ...


7

The needs for any language that you use for configuration files are the same, regardless of whether it is a programming language or not: The people who use it can do so reasonably effectively. If actual human beings aren't writing them, then it needs to be readable by programs. And possibly debugged by programmers. Lua's table syntax was actually derived ...


Only top voted, non community-wiki answers of a minimum length are eligible