Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
MESSAGEBOX
Message
From
04/05/2000 08:46:59
 
 
To
03/05/2000 20:52:14
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Title:
Miscellaneous
Thread ID:
00365597
Message ID:
00366019
Views:
19
>>Hey all.
>>
>>Maybe this is rhetorical.
>>
>>But why do almost all VFP code examples insist on using a #DEFINE variable for MESSAGEBOXs?

>I know and acknowledge all of the textbook reasons to use DEFINEs. Steve >McConnel states that "magic numbers" are always a no-no. A magic number is any >hardcoded numeric literal whose number is arbitrary. IOW, the only numbers you >should have in your code are like 1 for a loop, or 2 for an array dimension. >All others are bad. I agree.

>BUUUUUUUT. The practical issues involved with littering your code with >constants make the practice unbearable, IMO. At least in VFP. VFP is extremely >goofy with regard to the "scope" of an include file, and its behavior with >constants in the debugger, and its sometimes mysterious tendency to forget >where include files are. As a result of these PITAs, I almost never use >defined constants.

I have to agree with Steve McConnel on this point, "magic numbers" are always a no-no. Several others on this thread have made comments about readability & maintainability.

The main objections come from VfPs problems. The question I would put is should you reduce readability & maintainability because of a fault of the tool. Sure the client wants a working application, preferably quick & quickly. But they also want something that is easily maintainable & it may not neccessarily be the original programmer doing the maintainence.

Something that just came to mind was - if you were using a hazardous piece of equipment which was a PITA because of the safety guard, would you remove the safety guard to improve ease of use ?
Mike

"I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong." - Richard Feynman
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform