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 ?

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.

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

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