Continuing this near-religious subject, but hopefully only to clarify my prior reply...

><snip>
>
SNIP
>
>>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.
>
>That doesn't strike me as a strong reason to stop now. Standards that don't hurt and can actually help is a good thing. I using the scope and type because I can easily see when something like luVariable comes along. It will require more effort because its type can vary. I'm working with FoxPro 2.0 DOS code where no conventions were followed. Trust me, have a convention is better than not. Having one that is pretty common is better than having to waste time inventing another one or arguing about this one.

I *DID* say that until VFP (3) using Hungarian was pretty well mandatory.
And I have always said that some convention is better than none. (And that whatever it is in the program under revision ought to be kept/followed too).
I did write that (today, not FP 2.0) a shop standard of LOCAL for all memvar except... allows elimination of the scope part. The 'information' is still there WHEN IT IS NEEDED and still 'there' intrinsically for all others. Nothing lost.

SNIP
>
SNIP
>
>
>Do you dust three times a day or just once? "Public" is six times more typing than "g". More information is better than less information. Not including the type and scope is arguing against more information.

Ahhh... Maybe this is what that director was getting at! "g" is undoubtedly understandable by SOME people, but what's the harm in making something understandable by more people? Where is the value/wisdom of keeping the domain of programming mysterious and complex-looking?
And if "g" is faster to type (by 6 times) than typing "Public" then what about all the saved typing (offset by never again typing the "l" as local < s >? Given that you use scope all the time chances are good that you type more for scope declarations than the standard I propose!

>
>>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???
>
>
>I'm not so sure "we ... adapt new ... functionality" "readily" all that much. If so, there'd be no FoxPro 2.0 DOS code still running. There'd be no need for backward compatibility.

You've interpreted it too broadly. I *meant* "we" as (VFP) developers, not as the world in general. We drool at SESSION objects and ALINES() and CURSORADAPTER()functions and such yet we insist on staying with the antiquated Hungarian WHEN WE HAVE FAR MORE UTILITARIAN OPTIONS NOW AT OUT DISPOSAL! How bright is that???
That "typing" (on a keyboard) is best minimized is one EXCUSE that ought never to be acceptable. The purpose of typing is to communicate something and if it takes extra typing to get the message across clearly then that is what it MUST BE. Pretend communication is not communication at all. What we had available until VFP3 was makeshift at best. Why it continues is way beyond me.

SNIP
>
>TextBox is more than twice as long as txt. I feel a more important question is if I create a new control based on a textbox, as an example there is a control in MaxFrame called a TextPicklistValid. This control validates the textbox content against a table of values and can launch a form to selection from the list. The user can add to the list (and in my personal derivative, the user can edit, delete and find within the list). Now why should this control be called txt anything? I think it should be tpvSomething instead.

Again, the AMOUNT of typing ought not even be a consideration!
And your invention of "tpv" is your invention and so technically falls outside the realm of 'acceptable' too < s >. Who ELSE is gonna know what the heck you mean?... you're going to send the next reader into a tizzy searching Google high and low for the definition of 'tpv'.

SNIP
>>
>>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".
>
>Obviously I wouldn't put it like that but this particular issue isn't worth his attention.
>
>He should certainly suggest there be a convention, but not change one that is already there, because he can't read the code. He should not create a new one when there is one already in existence. He is micromanaging and is certainly aware of the pitfalls of that. The captain of the ship doesn't row unless something is dreadfully wrong.

Shouldn't create a new one when there is already one in existence??? How does anything ever get 'new' or 'improved' if it doesn't change with ne capability or new knowledge (that the new director might well be bringing to the table)?
I didn't see Renoir saying that the new director wanted all old code revised, and I bet the new director didn't say so.
I'd say the captain of the ship might just row if he thought that doing so might prevent something from going dreadfully wrong.
Have you seen the FEDEX commercial where the guy says 'but you don't understand...I'm an MBA' as a way of saying that the work he is being asked to do is beneath him. A director with a similar attitude as that is far far more dangerous than a director who will roll up his sleeves and get into the pit with the boys.

cheers

SNIP