>>>>>>>>>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?
>>>
>>>A performanceboost of 5 nanoseconds on displaying a messagebox as oposed to 100 milliseconds in readbility degradation. I certainly know what to pick here.
>>>mdot only helps in tight intensive loops while a table with many fields is selected. Really that is only 0.01% of my performance concerns. I'd better put effort in avoiding tights loops altogether.
>>
>>I think you may have intended to address your reply to Mike (he made the point about speed boost, and I think he meant it as a marginal boon to other more important advantages), though I'd say that the advantage of code readability using mdot is definitely way beyond the "100 ms" mark, since you don't have to constantly figure out whether the name you're reading in code is a field name, and alias or a variable.
>>*
>
>Not really. There are other ways as mentioned by others to distinguish fieldnames from variables, aliases etc.For example:
>In our system, each field in the database is prefixed with 3 characters like Ord_pk, Inv_pk
>Variables use a type prefix and is lower case followed by CamelCased name of the variable
>Aliases do follow neither
>
>Its all about consistency. There is no need for mdot for readability in our project and only in very few specific cases mdot is used (performance tights loops or scatter memvar cases). In all other cases mdot is not used at all. I personally find it hurting readability.
>
>I often see examples of using mdot, but only then where there can be confusion, IOW not when assiging values. That really does not make sense to me. If you're doing this for readability / consistency then you'd should do it there as well, or else it is only for the purpose of avoiding fieldname/variable mixups.
>
>So for me this boils down to personal preference and hardly a topic that is critical as long as you know the pitfalls.
>If I can create a 2 million line of code EMR application being put into a mission critical environments on 5 continents without having this problem no-one should.
I agree that every enterprise, or even project, will develop its own culture (conventions for coding, data structuring, etc), with which any new members joining the team will have to familiarize themselves before they can become productive. But mdot goes beyond that; it is also about avoiding the
unforeseen pitfalls. To give you an example (may not be realistic in your case, but just for argument's sake), consider that a new table is created today which may have field names conflicting with one or more existing variable names buried somewhere deep in an older program. If the vars are mdotted such conflicts would not occur, not should one worry about such things.
I agree that mdot could also be a matter of personal preference on readability, though for me, the stronger argument is avoiding the risk of undetected conflicts.
Also, it may make a difference when introducing new team members which would have to be trained in the enterprise/project culture. That effort is definitely warranted for permanent team members, but when working with outside contractors that may not be necessary or even recommended. For them, beyond the scope of their sub-project, the only thing I'd have to ask is to use mdot. Saves me a lot of time, and makes me sleep well at night :)
*
