<snip>

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

I've seen it first hand ;)

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





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


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.

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


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

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.


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

Good. I wasn't clear on that. Thanks ;)

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

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