>>One of my hang-ups is the spacing. I got spoiled by the QuickBASIC editor which would take a=b+c and make it a = b + c. The same would be applied to x=MyFunc(parm1,parm2) and it would become x = MyFunc(parm1, parm2). The insertion of the spaces is carried over into the VB editor and I hope that we can look forward to VFP doing the same in the next version. Additionally, indentation is supposed to indicate the sub-ordination of a code block, either logical or iterative. So my individual CASE var = statements have the code below indented.
>
> Amen. What is it with programmers and not using spaces? It makes reading the code a lot easier.

All I know is that when I first saw this feature in QB my immediate thought was that MS must have thought it important enough to build it into the editor. It served to reinforce what I was taught in school. Namely, that if we didn't do it, we'd get the assignment back with a big red "Do Over!" on it. Needless to say, I never got one of those.

>>As I said earlier, in my usage I don't really care what the value is. I care more about what it represents. To me, they represent abstractions of values, and which may change in the future, not values themselves.
>
> Sure, but when you're debugging you never quite know where the source of your problems may be. For example, if you're running a loop that checks some incrementing variable against a constant to decide when to exit, it might be really important to know the value of the constant so that you're sure the loop will exit at some point. If your variable is never going to be >= constant you might have a problem.

There are cases where this can be a problem. Not saying that it's the wrong type of place for the use of a constant, however, this sort of situation would give me pause to evaluate whether or not it was the best solution. For my money, the MESSAGEBOX() function wouldn't fall into this category.