>Hi Walter
>
>Thanks for answering ... for Jim.
>
>>Hi terry,
>>
>>Sigh ... here we go again.

>Why sigh? Have I asked before?

No you did not, but it is a frequently reoccurring topic, where through time really not much has changed. For example see: Naming conventions again........ Thread #258085 Message #258085

>>>What have you gained from missing out "ln" or "lc"?
>>
>>I could anwer with the question. What do you gain with ?? Well, I know the argument about knowing the type in preventing mistakes, but in most cases, it just does not cut it. I rarely come across a circumstance where I cannot determine the type of a variable and I desperately need to know. You might be right in theory, but in practise it is just not worth it.
>
>Not WORTH typing in "lc" or "ln" at beginning? SO much effort! I presume you haven't had to maintain someone's prog where they have the line like:

It is not about the extra efforts to type, but the extra efforts to read and understand.

>ttime = MyFile.Time
>
>From that you can determine:
>1) that MyFile.Time is a 4-char field and not DateTime
>2) ttime is meant to be char and not DateTime
>3) where the hell ttime came from (not declared in the current proc, no "g" to show it's global, so no knowing if it's just been created on-the-fly, in the above line, or already has a value from somewhere else)?

Hmmm, not sure what you're trying to say here, but time is most often implemented as character 4 or 5, not as datetime. But the type in itself does not say much. I've came accross instances where time was stored as a numeric value (seconds since midnight) in a character variable. Now tell me how naming conventions are telling me that?

In good practises, global and private variables should be very limited and I have no problem if those are marked with a scope operator. For the local ones (the vast majority) I see absolutely no benefit in prefixing this with a l. It is already assume that a varaible is local. OTOH, VFPs global variables are not prefixed, so why should application depended variable be ?? Else we should have VFP variables like _goScreen, _goVFP, _gnTally.

>>>personal rule being the operative expression! Surely Hungarian is to get round people's personal prefs and make everything more universally understandable.
>>
>>You could not be more wrong here. Do you happen to know the complete hungarian notation. What its inmediate purpose was. How it is to be ported to the VFP platform ? Do the same motivations and rules apply to the VFP platform ?? How many versions of hungarian notations are out there ??
>>
>>There is simply *no* one standard for hungarian notation on the VFP platform.
>
>I thought we were talking about H Not. as applied to VFP recommended naming conventions here. Hell, I wasn't even aware of the term before joining the UT.

If you look at the variations on hungarian notation VFP developper from all levels are using you can only conclude that there *IS* no standard. The fact that YAG has used this notation in codebook 3, should not imply that this is the standard. Lots of the VFP source code from microsoft violated the same rule. The help documentation seems to only use a prefix for global and omitting it for local ones. But even here you come accross example which don't use prefixes at all. Look at the PRIVATE help topic where simply Val1 and Val2 are used.

In short, Microsoft themselves don't even apply naming conventions consistently.

>>Because hungarian notation bring problems in readability also (lnAccountNumber can be easily read as In - Acount Number, and confuse people. No matter how hardcode programmer you are, you can read plain english way easier than hungarian notation and therefore at least my brain can get confused with hungarian notation).

>But if you're adhering to HN then there WON'T BE any vars beginning with "In" (either "gn" or "ln" or, if wishing to distinguish between float and integer, maybe "li")

I mean that the L can be easily confused with the I esspecially in some fonts. It is just about reading. I'm used in reading plain english rather than identifying the variables and filter out the extra information in the notation. It really disturbs me to have a scope prefix (personally, I'm using a type prefix, but only because I'm used to it and avoid conflicts with fieldnames).

The readability arguments in favour of hungarian notation are less significant to the following:
- Clear variable names (so no ldinvdte, but InvoiceDate)
- Clear program structure with enough white space.
- Comments where needed.

>>I agree with Jim, If they cannot find out by looking at the code, they should be looking for another job. It is knit picking. Esspecially since we are able to specify the type of a variable in code (eg. LOCAL MyVar as Char)

>Sorry but that's bol**cks". Just cos you'tre good at the job doesn't mean you should have to strive when reading someone else's mess. See my example above.

See my arguments about hungarian notation beein irrelevant to the readability of the code. If have to strive thorugh someone else his code, it most likely is because:

- People used total unreadable variable names (like ldInvDte).
- People are making a mess out of their program structure (JSP like long winded nested DO WHILE loops)
- People do not explain why something is done.

In my experience naming conventions are *SELDOM* enhancing readability and people using this arguments are talking about a theoretical standpoint rather than having experience with it. I've looked an awfull lot a code from other developers with different naming conventsions, but I have never, ever felt that it helped me a lot to understand the code. In some cases I could see the naming conventions were just applied wrong (You cannot do a STR(cVar)..). If naming conventions could mislead you, then it better not to apply it at all.

>BTW "It is knit picking." refers to the eggs of lice, as in "nit picking" - just to be nit-picking! :-)

Thanks for the correction...

Walter,