Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
MESSAGEBOX
Message
De
04/05/2000 08:46:59
 
 
À
03/05/2000 20:52:14
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Titre:
Divers
Thread ID:
00365597
Message ID:
00366019
Vues:
20
>>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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform