I have recently been reading The Pragmatic Programmer which states that:


  Details mess up our pristine code—especially if they change frequently. Every time we have to go in and change the code to accommodate some change in business logic, or in the law, or in management's personal tastes of the day, we run the risk of breaking the system—of introducing a new bug.
  
  Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master (Kindle Locations 2651-2653). Pearson Education (USA). Kindle Edition.


I am currently programming a web app that has some models that have properties that can only be from a set of values, e.g. (not actual example as the web app data confidential):

light->type = sphere / cube / cylinder

The light type can only be the above three values but according to TPP I should always code as if they could change and place their values in a config file. As there are several incidents of this throughout the app, my question is:

Should I store possibly values like these in:


a config file: 
'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value
a single table in a database with one line for each config item
a database with a table for each config item (e.g. table: light_types; columns: id, name)
some other way?


Many thanks for any assistance / expertise offered.

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