The same question arises in most of the projects I work on. Usually, I do this:

1. 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.
2. Values will probably change, but changes will not affect program logic – config files. Example: list of “how did you find our website?” options for a dropdown list in online purchasing form.
3. Values are likely to change frequently and/or meant to be edited by non-developers, but yet these changes will not affect the logic – a database or at least a key-value storage with some user-friendly interface for editing.
4. Changing the values will affect the logic – probably the system needs redesign (often true) or some business rules engine is needed. The most difficult case I’ve seen so far was psychological tests constructor my colleague worked on. Each type of test may have its own scoring system which may vary from simple addition to multiple characteristics scales with positive and negative values or even human evaluation of answers. After some discussion about this project, we ended up using Lua as a scripting engine, which totally conflicts with the ability of non-developers to create new tests (even though Lua is a relatively simple language you shouldn’t expect that a non-programmer will learn it).

About the quote from TPP. I think it’s true for pristine code, but in real life, you better start simple (KISS principle) and add features later if they’re really needed (YAGNI).

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 of enums doesn’t do a whole lot of good. I might recommend a config file, if you really want to avoid hard-coding the values.

(I’d warn against going too far in avoiding hard-coding, though. In any non-trivial system, there will be assumptions about business rules and requirements, whether the authors realize it or not. Even if you somehow manage to avoid all assumptions and soft-code absolutely everything, you basically just end up with a “rules engine”, a sort of system-within-a-system and/or meta-language, and you have a bunch of stuff in the meta-language to implement the rules. You haven’t saved any work or gained any flexibility; you’ve just had to build and/or learn another language.

Now, if you want to find and use an existing rules engine, that might save you a bit of work (along with answering the question of where to store enums). But building your own just doubles the workload and inevitably gets you a half-assed system built by people who really don’t know how to make a decent rules engine.)

In general a database should be used for data and a config file should be used for configuration. (as the name suggests 🙂 ). Keeping configuration in the database is bad separation of concerns and should only be done if you have a good use case to justify it.

There is a balance to be struck when deciding how much configuration to use. You should treat your config files as much as a part of an application as the code. Keep it as terse as possible. Its very easy for applications to suffer from configuration bloat where you end up with a huge xml file full of magic strings.

In the case you describe it would be reasonable to have a configuration element to define which css file to use. (you could then just change it if requirements change). It would be overkill to configure the style of each element in the config file