A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
93

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, ...


45

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 ...


21

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 ...


20

Personally I would only use constants as default values, and let them be overridden by values from a configuration file. If the application takes command line arguments, then those would in turn override the configuration file parameters.


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

I personally prefer the single-row tables for most things. While it's true that it is less flexible, unless you are expecting dynamic behavior, it's perfectly acceptable to add extra columns later if you need to. In a way, it's the equivalent of using a dictionary/map to hold name-value pairs vs having class members when programming. Granted, it's not a ...


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

I think the first one will give you the ability to create a config object elsewhere and pass it to ExampleA. If you need Dependency Injection, this can be a good thing because you can ensure that all intances share the same object. On the other hand, maybe your ExampleA requires a new and clean config object so there could be cases where the second example ...


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'd generally go with option 2 BUT I'd have multiple columns to enforce data type ConfigOption | textValue | DateValue | NumericValue Option 1 Has the additional Benefit that you can very easily "Swap" entire Configurations by adding an Active Column.


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 ...


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

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 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

If your team find email disruptive or tune it out, something is wrong (they've set their notifications to be too in-your-face, or they're getting too many private emails, or they haven't set up filters/triggers properly). Email is, in my opinion, the perfect tool for this. Set it up right and it will serve its purpose. You could do something silly and ...


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

Do not forget about testability! Usually if the behavior of Example class depends on the config you want to be able to test it without saving/modifying the internal state of the class instance (i.e. you would want to have simple tests for happy path and for wrong config without modifying the property/memeber of Example class). Therefore I would go with ...


9

With PHP in particular; the difference between an .ini file and a .conf.php file is negligible. Using PHP directly for configuration has the distinct advantage of only needing to relate to one well-defined, portable syntax for configuration, and the fact that the configuration file is properly code is occasionally useful. Compared to that; an ini file has ...


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

For me, whether you go single-row or EAV depends on how you want to consume them. EAV's power is that new data can be added with no change to structure. This means that if you want a new configuration value, you just add it to the table and pull it out where you want it in code, and you don't need to add a new field to the domain, schema, mapping, DAL ...


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

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 ...


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