The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Is using data files for config a sign of good design?

From: http://it.slashdot.org/comments.pl?sid=180354&cid=14930654 about using .net :

> It took over 3 minutes to recompile. Three minutes
> is a r-e-a-l-l-y l-o-n-g time when you've only
> changed one source file! No, I wasn't rebuilding
> the whole solution/project each time in such instances
> just making tiny tweaks to specific lines of code,
> initial values (positions, velocities, durations, etc.),
> state machine states, etc.

>>A really good design would put at least initial
>>values in data files...You shouldn't need to
>>touch the binaries to tune the game!

Isn't code a data file too? That's one thing I've never understood about the XML craze. Java, C#, etc is a file format and they allow value initializations and complex structures.

I need an XML parser, I need a code parser. There can be errors in both. In the XML/data file approach I have to map the data file to my code values. In the code approach it just works.

If the XML approach is faster then isn't that a tool problem rather than a paradigm problem?

I wouldn't consider slapping value in a data file obviously good design. It's just a work around that people accept without thinking.
son of parnas
Thursday, March 16, 2006
 
 
Code changes require a re-compile and a software update.

An ASCII config file can be tailored by a user.

I.E. Just because i like tangerine text on a turquoise background when coding, other user's of said editor shouldn't be forced to us it too...

Its good design when it separates things that change from things that don't and makes the app more useful/less buggy.
Honu Send private email
Thursday, March 16, 2006
 
 
"An ASCII config file can be tailored by a user."

Just make sure there is a process for validating the file *prior* to loading it.  This leaves lots of room for error.
KC Send private email
Thursday, March 16, 2006
 
 
Hardcoded fixed values in the source code are generally considered as bad design - make it a constant instead, e.g. use

#define MYVAL  1067

in C as one possibility.

When compiling the thing, the value is now again hardcoded in the binary. Why should this now be considered as good design, or at least as not-so-bad design?

This is relative, of course. The above MYVAL may define an array size, which can't be changed anymore once it is compiled. But it could as well be a dynamically allocated array, and the value could be used to finetune the performance on the specific machines, e.g. for different cache sizes.

The questions are: Is the data change meant for a programmer or for a user? Is it a good idea that the user (without knowledge of the internals) is allowed to change the value?

Another question is the purpose. When talking about games, throw as much as possible into data files - else the players are forced to patch the binary when creating their own levels. And nothing is more annoying than features that are used in the original levels that can't be used in user-created levels. E.g. the level editor of the older game Settlers 2 does not allow to use ports that are used in the original campaigns. Thus you are forced to use only one large continent instead of islands. You can only use them by substituting the original levels with your own port level.
Secure
Thursday, March 16, 2006
 
 
> #define MYVAL  1067

It would be more like:

class Config
{
public:
  /** Some doc.
    */
  int myVal= 1067;

};

Which is documented, typed, structured, and expandable.
son of parnas
Thursday, March 16, 2006
 
 
class Config
{
public:
  /** Some doc.
    */
  enum { myVal= 1067 } ;

};
Nitpicker
Thursday, March 16, 2006
 
 
Using enums as values aren't typed and they can't be changed.
son of parnas
Thursday, March 16, 2006
 
 
son of parnas:

The question remains. Is it a development-internal thing, or should a user be allowed to change it without too deep knowledge of the internals? Another question is if the config is hardcoded as a whole, or if it already is at least partially saved.

Nitpicker:

WTF?
Secure
Thursday, March 16, 2006
 
 
As a general rule of thumb, any parameter that the user can change without breaking the application, should be in a data file. There are obvious exceptions, and there are cases where you don't want to offer a convenient way of changing those values (power users only).

I think it's good practice to at least ask yourself that question when you first design an application; what are the attributes that you'd like to be able to change, without recompiling the application? A good design reflects the answer to that question, for example, no user tunable parameters, a few parameters, or a lot?
TheDavid
Thursday, March 16, 2006
 
 
It depends on what you mean by config.

class Config
{
public:
  /** Some doc.
    */
  string dbServer="productionbox.com";
  // my dev box
  //string dbServer="devbox.com";
  // qa
  //string dbServer="qa.com";

};

In the case from the original slashdot thread (tweaking in-game object behaviour) a scripting language might be the best trade-off.
Grant
Thursday, March 16, 2006
 
 
Application code is parsed and compiled when the application is released. For all intents a purposes the information of the application itself isn't changing anymore, so it's not configurable.

An xml file read by the application is parsed and interpreted/converted/used in someway and may be even internally compiled somehow. But this is done at runtime by the application so it makes since for it to be stored in a format that can be changed easily without the need for the app to be recompiled to be used. If the data should never ever be changed for that build then it would make since to have it part of the application.

To me code really isn't data in the same since an xml/data file is data. It's more of an instruction set that in addition to instructions contain preset values. I think the biggest thing with the xml craze is you don't need a specific file format reader. All that's needed is an xml parser that returns strucured data. How it's used is up to the application.
TrippinOnIT Send private email
Thursday, March 16, 2006
 
 
> To me code really isn't data in the same since an xml/data file is data

That doesn't make it true though. You are putting config in a seperate made up language for what reason?
son of parnas
Thursday, March 16, 2006
 
 
> As a general rule of thumb, any parameter that the user can change without breaking the application, should be in a data file.
... but consider the tradeoff that the more parameters you have, the more combinations you will need to test.
Joe
Thursday, March 16, 2006
 
 
A) It sounds like either an under-powered machine, abuse of the language and runtime, or both. Really, if it takes an app 3 minutes to start then something funny is going on.

B) Only the king of all retards would have a datafile loading module that doesn't do some type of sanity check on the data, but even then when you're doing development you can have little or no validation while experimenting, then recompile with stronger checking once you know what actually works.

C) Bytecode interpreters (even with JIT) have performance issues that native compiled languages don't. This is, um, obvious. Really, it may or may not be an issue depending on circumstances, but it shouldn't be a surprise.

D) Many people believe that garbage collection means that you can allocate memory with wild abandon, and not suffer any consequences. According to interesting articles on MSDN, an understanding of how the system works will allow you to carefully manage your memory acllocation in order to maximise efficiency. Over on Raymon Chen's blog ( http://blogs.msdn.com/oldnewthing/ ) there's many interesting articles about the deep and dark corners of C++, Windows, and the x86 architecture that can cause subtle and hard to fix bugs. Occasionally there's C# fanboys claiming that C# is better because you don't need to know anything about how the compiler or platform work. They are wrong. .NET may be the greatest gift that the gods have bestowed on mankind for all I know, but knowing the details is still important.

Thursday, March 16, 2006
 
 
"Bytecode interpreters (even with JIT) have performance issues that native compiled languages don't. This is, um, obvious."

The assumption here is of course that we're talking about optimal interpreters and optimal compilers. In the real world, it's most likely not the case, so you'll have to test it first. That should be obvious too, but somehow it has turned out not to be so.
Peter Monsson Send private email
Thursday, March 16, 2006
 
 
I have a similar bone to pick as the OP.

Okay fine, put user-definable options in config files and validate them when reading, check. But this is not the whole story. Many frameworks, probably Java in particular, use config files to configure them, often XML. Examples abound, Struts, Tapestry, Spring etc. etc. (let's not get started on EJBs).

In many of these latter cases the external configuration is just over-engineering and a design flaw, as it trades a simple and obvious solution (hard-coded constants) for a complex solution with no added benefits.

My favorite aversion is configuration files that specify actual class names (all above examples qualify). How dimwitted to move that out of the code (where the class names are compile-time checked for correctness) and into dumb text files.
jz Send private email
Thursday, March 16, 2006
 
 
I agree class names should not be in the config files, with one collorary that I'll get to in a moment. "Ordinary users" shouldn't be able to change the class names because of the security and stability issues that causes.

The collorary: your application explicitly allows the user to add custom plug-ins. I should point out that's a decision you will make up front and you will design your application accordingly (i.e., sandboxing and robust error catching).

If you don't want the user to be able to add their own stuff, then you should explicitly design the application not to allow it in some shape or form.
TheDavid
Thursday, March 16, 2006
 
 
"In many of these latter cases the external configuration is just over-engineering and a design flaw, as it trades a simple and obvious solution (hard-coded constants) for a complex solution with no added benefits."

Hardcoded constants, config files, and anything else are just tools that should be used for the right purpose. A fool with a tool is still a fool, if all you have is a hammer any problem looks like a nail, [insert your favorite here]

Step A: Ask yourself what you want to achieve.
Step B: Chose the right tool for the job.
Step C: If you've omitted step A, stop and restart, or live with the crap you now have produced.

And since 90 percent of anything is crap, we don't have to search too hard to find enough negative examples.
Secure
Friday, March 17, 2006
 
 
IMHO, its helps to have configuration in a separate text file editable from outside. However, validating the configuration file is important. I'd provide a GUI to manipulate the config file, and hide its existence from users. It may seem like a lot of work, but once you have a set of classes made, it can be used forever in all your applications.
JVM
Saturday, March 18, 2006
 
 
> and hide its existence from users

Incidentally, the 'it' refers to the config file, and not to the GUI.
JVM
Saturday, March 18, 2006
 
 
"Incidentally, the 'it' refers to the config file, and not to the GUI."

LOL! I like the other reading.
EKB Send private email
Sunday, March 19, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz