Actually, Mike, the issue is a more fundamental one.

The essential argument offered by all other respondents (me being the lone dissenter in a long list of respondents) is, paraphrasing... 'we've always done it that way and we all understand it and so it works very well and should be continued as-is' and many have added '...and what the hell is a director doing looking at code anyhow?'. A few have offered the additional reason along the lines of 'and it helps to be able to see all the same typed variables listed together'.

Now I'll be the first to admit that I have, as I saw someone else so neatly describe it, 'a genetic predisposition against Hungarian notation in code'.

Now to the point...
We all bitch and complain to MS to add new feature this and new feature that and improve old feature this and old feature that, etc.
With the advent of VFP3 MS did just that as regards memvar name lengths and field name lengths when they are part of a (new then too) 'database'.
Now until VFP3 Hungarian notation was virtually a MUST USE convention, given that both memvar names and table field names were limited to 10 (meaningful) characters. You could code more for memvar names but only the first 10 characters were used by the compiler.
This limitation meant that we could use only parts of names in memvar names so they looked like gobbledygook anyway. Using up 2 of those characters was 'costly' in terms of clear description but helped not only with describing the type/scope but also with differentiating the memvars themselves. Of course they HAD to be prefixes because suffixes would only cause confusion with the terse part-names that formed the real 'description' of the memvar.

Now here's the rub... we developers are only too anxious to adopt new features and functions yet we use any number of reasons to reject one of the most utilitarian revisions - (effective) removal of the limit for memvar naming!
Arguments I've seen include 'I don't even notice the type/scope codes anymore' (begging the question of why they are deemed needed at all then) and 'I hate typing so keeping names short and sweet minimizes the problem' (I hate dusting too, but I still do it and I don't just pretend that I did it) and 'it keeps all same-typed/scoped memvars together in sorted lists'. Funny thing but *my* interest in using any sorted lists of memvars is ALWAYS on finding **related** memvars and I can say categorically that the commonality is NEVER type/scope. Of what possible help can it be to have all local logicals listed together???... that ensures that I have to look at SEVERAL DIFFERENT PARTS OF ANY SUCH LIST for something relating to, say 'Cust'! How helpful is that?!?!?!?

With the advent of LOCAL (also in VFP3) a shop standard saying that LOCAL should be used exclusively except in specific circumstances totally obviates any need to code the "scope" code of Hungarian. For those that do not conform then camel-case offers that the full word be useable and as a suffix. For example: ActiveCustomerPublic.
The exact same is true for 'type' codes. Why, and to what value (any more) is it preferable to put them at the FRONT?!?!? Because we've always done it that way? If that's it then how come we so readily adapt new or revised functionality at all???
But it goes a little further with VFP. The recommended 'standard' (which MS itself doesn't use or impose in VFP itself) includes the prefix "txt" for a Textbox control name. Now what is the intrinsic value of that inasmuch as 'type' is concerned? A textbox can hold a date or a number as well as a character value. Sure, it helps to confirm what it is NOT. But so what??? And what is so hard about using the word "Textbox" at the end of the name?... Does "CustomerNumberTextbox" or "CustomerNameTextbox" present some hardship or provide less information than, say, "nCustNo" or "cCustName"? Ooops... where should I put the "txt"???

As regards "the whole code base"... no. A whole program, yes, but a whole code base, no. How else would one be able to adopt new innovations if such were restricted to wholly new code ONLY?

Finally, as regards a director sticking his nose in where it doesn't belong...
The person **IS** the "director" and as such that nose belongs anywhere in his/her department that it wants to go. That director may have been a developer in a previous life and may well have some good and valid reasons for stipulating what s/he is stipulating. To brush it all off as the rantings of an intruder is self-seving at best and offers nothing of value in terms of relief for the requester. Let me see you walk up to your director and say "mind your own business buddy, and I'll mind my own".

cheers

>Hi Jim
>
>An intelligent director would delegate this function to a specialist. The director should not be reviewing code in the first place.
>
>Microsoft's lack of use of Hungarian Notation for properties isn't the issue. Much of their example code is handed down from previous versions. System memvars must retain the original format to be compatible with the backward. There isn't any consistency with variable naming because it is simply example code. MS doesn't program in VFP for a living. The real question is do they use Hungarian Notation in the code they write that makes up VFP? They (MS) have provided a Variable Naming convention section in the help that should be enough to convince this director to leave well enough alone.
>
>If I'm not mistaken, I believe you've said that style should not change throughout the codebase. If that's true, new code must keep with the conventions of the old.
>
>
>>Now that's one intelligent director you have there, Renoir.
>>
>>Way back when (it as called VFP3) we got an extension on memvar name lengths (and on field names when they are in a dbc). We also got the "LOCAL" declaration. I think both are now 'limited' to 128 characters though the number 44 stick in my mind and may be a limit for memvar names.
>>
>>Now I know that typing is a drag, but with Intellisense going to be 'fixed' for WITH...ENDWITH and also preserving case as entered the job is alleviated somewhat. So now (with 128 or 44 as the limit) we can properly describe our variables, including PEMs. You'll notice that MS doesn't use Hungarian notation (or any derivative thereof) in the names they have chosen for PEMs, system variables, etc.
>>
>>So I'd say that you could even do away with the _lc suffix if you adopt something simple like all variables are assumed LOCAL (and actually use the full word as the suffix for any that aren't, like "MyVariablePublic") and adopt a simple policy for oddball collisions like a key being char but having all numbers in it.
>>A variable named "EverythingGotWritten" is clearly a logical. A variable named "CustomerFirstName" is clearly a char. A variable named "DateOfBirth" is clearly a date. Similarly a variable named "xx" should clearly be understood to have short-lived any type depending on context.
>>
>>By the way, I'd say the director is right for new programming but that old programming should continue in its original style, whatever that is.
>>
>>cheers
>>
>>
>>>Out director has said that we must find another way to name our variables as he finds it difficult to read. Currently we use lcMyVariable to denote a local, character variable. He would like to use MyVariable_lc instead. We were also considering lc_MyVariable and one person thought that MyVariableLC was reasonable. Any thoughts? And if this has been covered already then just point the way please. I still would like to know what others think just about this specific example though. Thanks!
>>>
>>>Regards, Renoir