Craig,

>>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
>

I know that, you know that, but does the programmer who sees this for the very first time see this? I don't think so. Also be aware as stated before that you cannot describe the rule with an equal sign because it is also used for comparison in which you have to use the m. at the left side to avoid field, variable conflicts.

There are some instances where I don't know whether I should use the m. or not. For example I could not tell if I need the m. if I was passing a variable explicitely by reference with @ without trying this.

IMO this rule is too complex to use it in a coding standard. IMO should be use it consistently for all variable or not at all.

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

The hungarian notation was invented for use in strong typed language ( C ). The type indicator has been introduced to tell if a variable was holding a handle, pointer, short, double, word, long etc. C validates the types even at compile time and will raise errors when the type does not match. So here it is extemely important that you the variable includes the type in the name as maintenance on these programs grow to be a disaster. Think about it, why do have all examples in C/C++ have type prefixes like hWnd, pStruct, dWord etc. It's absolutely neccesary. But tell me why do have abstract structures used in many API do not follow this standard?

A weak typed language like VFP does not realy care because all those types are handled as a numeric. However the I do use a type prefix to identify the type, but only the base types (C=char, D=date, T=Time, L=Logical, N=numberic, x=Unknown)


>>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.

>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):

See my remark above about the difference between strong and weak type language.


>"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."

I don't see this apply to VFP. We've got about one really important scope operator and that is the underscore ("_") which references to a internal (global) VFP variable. OOP programming should prevent long procedures where you have to wonder what the scope of a variable is. Like you said yourself you only use 1 PRIVATE variable. Do you name it pApplic or gApplic, poApplic, goApplic? Why is just Applic not enough ?

I believe that procedures, methods and functions should be compact. If you end up writing methods of several hundred lines of code, you should seriously wonder if that is correct. I know this behavious is just an inheritance from the JSP times and widely used in clipper and foxbase programs, but this is really a bad habit.

Smaller pieces of code typically do just only one or few things, and don't use many variables. It is clear where variables are used for and where they come from.

>"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."

This has happend to me quite a lot actually, ending up with a variable cRet that container a boolean.

>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.

Exactly, so why do we need a scope prefix here ?

Walter,