Hi Walter

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

Aye, but that was some 6 years ago. Only full members would be able to search on the subject so how is a fairly recent member (like myself) supposed to know "it's all been said before"?

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

Just what I said in the numbered points

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

God, I hate the VFP vars that begin with "_" (now that IS a pain to type - having to shift to get it!).
Good point about not using the "l" prefix, esp. in light of more recent "diktats" that thou shalt not use any global variables if thou cnast avoid it.
>
>>>>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.

My point is that one should adhere to SOME notation, along the HM lines. For example, I always prefic my combos with "cbo" and cursors with "csr" - others I've seen use "cmb" and "crs" respectively. I've no problem with this, if they're consistant with it.

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

OK, forget the "l" as you've sensibly argued above.

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

Still no proof that "InvoiceDate" isn't being used as, say, char, and picked apart in some code to manipulate the month, year, etc., and not actually a fdate field.

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

Well, I wouldn't say that was unreadable - I take it immediately to be local date Invoice Date field, but, I agree with you that lazy-arsed var names should result in the shooting at dawn of the programmer. Just the inclusion of one letter, "a" would have made that amply readable. There's no excuse when we can copy and paste var names, use an abbrev. if wished but globally replace it with something more readable afterwards, etc.

Anyway, I can't be arsed arguing the toss over this, but if you'd seen the conventionless code that I've had to decypher in the last few years you'd see ample argument for using HM

Terry