>Ed,
>
>>>.PagClientPage. ??? Seems overhead to me.....
>
>>Can you explain this? Aside from Carpal Tunnel Syndrome consideration, how does a longer name, or a name that differs from your standard, impose overhead? VFP tokenizes this when it compiles the code, so a name, regardless of its size, takes up the same amount of space in the compiled code, except maybe for a few bytes in the name table. Internally, VFP doesn't care. OTOH, if the naming convention provides some metadata to the programmer in a meaningful and consistent fashion, the long name provides something useful at a cost of perhaps a few keystrokes at worst.
>
>Carpal Tunnel Syndrome ??? What this ?

A repetitive stress disorder from typing a great deal.

>
>Well, By overhead I meant that .PagClientPage is refering to a Page object twice. Just 'ClientPage' says it all. It's like a textboxObject called txtLastNameTextBox while LastNameTextBox is sufficient.
>

All you've done is moved the reference from prefix to suffix. That's fine, but it's no different a technique, except for how you visually process the symbol - you have to read the entire name and begin a cognitive process, since it's at the end of the "word" and the length is not consistent or necessarily small. Prefixes can be scanned and reacted to before cognitive analysis of the name takes place, and are of a small and relatively consistent size and formation.

>>>THISFORM.MainPageFrame.ClientPage.LastNameTextbox.Value
>
>>>IMHO this has a greater readability.
>
>
>>All you've done is moved the control type prefix to a control name suffix, and there's no increase in understandability, at least from my POV. I'd recommend reading a few interesting articles from FoxTalk, A cRose by Any Other oName by Charlie Schreiner (August 1997), Keep Your Effective Naming Conventions by Steven Black (September 1997), and Development Checklist: Coding by Jefferey A. Donnici (February 1998.) How does this style of naming decrease overheap, where John's naming convention increases it?
>
>I Strongly feel that if you can write your code like plain english sentences as much as possible, readability improves. Looking at it from this angle, prefixes stands in the way of good readability. I think that if a beginning developer reads this style of naming, it would help him to understand what has been written.
>
>>BTW, if you don't subscribe to foxtalk, you can download articles for $5/article from Pinnacle Publishing's FoxTalk website. if you refer to back articles frequently, they sell CDs containing the articles and text (CD 2, the latest one they offered, covers January 1996-June 1998, and costs about $80 for non-subscribers.) The electronic subscription to FoxTalk runs about $15/month now, and includes the ability to search and download artciles from their site going back ~3 years. I find FoxTalk to be a very useful publication for me.
>
>
>I don't own a creditcard and for principal reasons I don't want to pay through the internet. Though you can pay another way, it seems to be very difficult if you're not living in the US. A colleage has tried to subscribe to Fox Advisor but after three issues he got a letter that his payment did not arrive...
>
>But I begin to realize that I definitely have subscribe to FoxTalk or FoxAdvisor. which would you recommend ?

If I could only subscribe to one, FPA certainly has wider coverage of new topics. FoxTalk has consistently had great content, and with the electronic edition available, the on-line search capability is great. I read both; Weatherhill pays for one, and I pay for the other. Since it enhances your ability to do your job, I'd approach my employer about getting the subscriptions. If you're a sole practitioner, in the US at least subscriptions to trade magazines are tax-deductible as necessary business expense.

If you do subscribe to FPA rather than FoxTalk, consider buying the FoxTalk compilation CD covering January 1996-June 1998; it cost ~$80, and there are a ton of useful articles from FoxTalk that came out in that time frame.

>
>>>But it is getting more complicated if you subclass the baseclasses. How do you distinguish your own classes from the baseclasses ??
>
>>Come up with a standard and stick to it. And document it. My own preference is to carry the inheritance detail in the name and continue to prefix with a type (it can get very complicated when dealing with composites, so a standard pays off tremendously here), but that makes for even longer names, with presumably even more overhead. or maybe less. I need to know how the prefix increases overhead before I can speak to that issue.
>
>In theory, I think you could be right, but in practice it seems almost impossible to stick to these standards, especially when 2 or more people work on one product. But even when it does I doubt that it improve readability.
>For example my menubutton could be called:
>
>mnuPersons (I think that if you call it mnePersonMenuButton, it is overhead)
>
>when using a standard.
>
>OR
>
>PersonsMenubutton
>
>When not. For readability reasons I would choose for the latter. Another programmer has to read the documentation (which has a nasty habit of getting lost) to know where the 'mnu' stands for, while PersonsMenuButton says it all.
>
>Walter,