>Really think about the concept. Do you have complicated if...then...else or case statements? Think how much easier things would be if you replaced them with a lookup table. How about the same string or number appearing over and over again? Use constants from a header file.
>
>I know now - yes I do those kinds of things when I can. But I call it "data driven" design - like cases where a menu prompt and it's action would be stored in a SQL table or DBF. When ever the program loaded the menu would be defined (with the new stuff) from the table. An SCX or FXP would be dropped in the run folder - or - the Install Shield Geek would write a clever patch to modify the EXE.


>I thought we all agreed that that modis was to be called "data driven". I think we need a parlimentarian!:-)

< Chuckle > It really doesn't matter whether we call it meta-data or data driven, because the principle's the same.

I haven't gone as far as defining menu options, but I have used it to determine whether or not the option is enabled or disabled.

>Sometimes for exotic "pricing" iterations I have a few IF/ELSE's. Most of my SEEK requests do not need an IF FOUND() anymore, so thats some progress (i hope). I am still overly retentive about my projects - I look at everything from a runtime "speed" or "clock" perspective. How to make it fast - how to get rid of that little anoying flicker. Why do my fonts bleed - etc.

No offense, Terry, but I wouldn't approach it this way. I'd strive for program correctness and quality before speed. The reason is simple, before I write the code, I have no idea where the bottle necks are.

Sure I might be able to make something a little faster otherwise. But would the user notice? OTOH, if I've created a correct, high quality system, it becomes easier to tune the code for performance.

>I used to scare myself running a project through the debugger. There used to be a lot of little things I took for granted that would recycle through a function more than once. The results were not affected - it was just knowing that I neglected some bit of housekeeping and allowed it to happen that gave me a tissel!

I'm sure all of us have done that. I found a situation in a legacy app this week where I did that.

>Development speed is not a real issue. I schedule in days - so I just work more hours to keep on schedule:-).

I think that you'll find that you can work a few less hours by concentrating on correct, high quality code rather than speed.