>
>Well, readability IMO IS a significant argument. The other disadvantage I see is that you and others (Craig, doesnt use a m. on the left side of the equal sign) seem to have certain rules for when to use a m. for a variable and when not to. In my eyes that seems rather inconsistant. I bett it it is for every user who first looks at without knowing the background.

Why would it be confusing. If you see a line like

TheValue = m.SomeVal + m.AnotherVal

it is clear that TheValue is a variable because:
1. You can't do and assign statement to a field
2. There is no . in front of TheValue, so it isn't a property.

>
>I don't see any significant value in the performance advantages/disadvantages that apparantly exists and seem to differ from version to version. Though percentagewise they seem to be significant (i've measured about a 100% difference with wide tables) in absolute sense it does just not justify the use (maybe in very specific cases). I'm just not convinced any user could tell the difference.

You're right, the user will not see any difference unless you are doing lots of assignments inside a loop. Therefore, my standards again hold up as the code is always consistant.

>
>As I already told, I see the advantage of explicitly telling VFP the variable is a variable and not a field. As I mentioned, I avoid this problem by having different naming conventions for fieldname and variables.
>
>>Drew Speedie's field naming conventions (which I use BTW) are similar. I think Craig was referring to your variable naming since you seem to not be using Hungarian notation.
>
>There is a lot discussion about hungarian notation but the common agreement seems to be that it is less usefull in a OO programming (For further reading: search the web for Hungarian notation).

But I think it does have great value in weakly typed languages. That's one of the reasons I use it.

>IMO, we still are stuck with old arguments that come from another programming environment and age. When we look at the modern OO prgramming environments it does make less sence to use it anymore.
>
>See also http://ootips.org/hungarian-notation.html.

Sorry, Walter, but your very reference supports my claim. From the reference:

"However, C++ is a hybrid language. [...] You can mix objects with primitive data-types etc.

Hungarian notation (or a variation of this) has its place in C++ when referring to data that really DOES have a particular type, by its very nature. eg. Handles can have a 'h' prefix (eg hWnd) - this is simply a shorthand convention that save writing something like 'handle_of_Window'. Similarly 'nLines' is short for 'number_of_lines', 'bOpen' is short for 'is_open', 'pData' is short for 'pointer_to_data'. As a convenient (and hopefully consistently used) shorthand, such a notation can save on extra typing - and less typing can mean less typing mistakes and more compact (but just as readable) code.

However, like all things, it should be used consistently and appropriately."

VFP, like C++, is a hybrid language. In addition, the same reference supports using an additional letter to signify scope (which you have stated you don't use):

"Also, in C++, what is often more important to know about a variable is not its type, but its scope (local, function arg, file static, member, static member, global etc). This can be easily encoded with a Hungarian-style notation, such as what MFC uses, with m_ for member, c_ for static members etc."

However, there is claim for your arguement:

"When the type of a variable changes, it is not likely that you are going to hunt through all the code and change all occurrences of its name. Especially during the schedule crunch. Thus, the variables name will become a lie."

I'm not sure this applies in a good VFP app. If you have properly designed and coded the application, an extremely high percentage of variables will be LOCAL and kept in a very short section of code. Changing the letter is a very easy search and replace.