Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Foxpro Life
Message
 
À
12/04/2017 10:02:38
Mike Yearwood
Toronto, Ontario, Canada
Information générale
Forum:
Visual FoxPro
Catégorie:
Contrats & ententes
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Network:
Novell 6.x
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01649781
Message ID:
01650090
Vues:
73
>>>>>When I write the code I will never have the problem of using the m.dot or not using the m.dot. My coding convention uses the above rules. However, when we use classes that the community has written now we could have potential naming conflicts between variables and fields. So having the compiler enforce the rules is preferable.
>>>>>
>>>>
>>>>Just want to point out that the Hungarian naming convention isn't infallible. While it's a bit of a stretch, it's certainly possible to have a field name lOrange and a variable named loRange. I haven't gone hunting for other examples, since one makes the point, but I'll bet there are others that are plausible.
>>>>
>>>>In my view, VFP developers should always use mdot where there's any chance of ambiguity. That's even more important for tool writers since they have no control over the naming of fields in tables their users create.
>>>>
>>>>Tamar
>>>
>>>To avoid ambiguitiy as much as possible I tend to use objects instead of simple variables. An object with the same name as a field can be used without m. as long as you reference any of the object members. It also provides you a level for extension methods that can be very useful in daily coding life.
>>>
>>>CREATE TABLE Test (loTest C(10))
>>>INSERT INTO Test Values ("Field")
>>>LOCAL loTest AS Label
>>>loTest = NEWOBJECT("Label")
>>>loTest.Caption = "Label text"
>>>MESSAGEBOX(loTest)
>>>MESSAGEBOX(loTest.Caption)
>>>
>>>Therefore I use classes for repetitive work like for counters or strings:
>>>
>>>* Instead of 
>>>LOCAL lnCounter
>>>lnCounter = 0
>>>lnCounter = lnCounter + 1
>>>Messagebox(TRANSFORM(lnCounter))
>>>* it is better to do
>>>LOCAL loCounter AS Counter OF Utils.vcx
>>>loCounter = NEWOBJECT("Counter","Utils.vcx")
>>>loCounter.DoAdd()
>>>Messagebox(loCounter.Value_toString)
>>>
>>>
>>
>>I would do Messagebox(m.loCounter.Value_toString). That would eliminate any risk of conflict with a table alias/fieldname locounter.value_tostring.
>>*
>
>and you get a tiny performance boost for free. Who doesn't want free speed boosts?

Sure. And it helps with readability, too :)
All in all, I would call it mdot disambiguation.
*
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform