>John,
>
>>Naming conventions are as critical to code as syntax is to a written human language. Now, I would agree with you that scoping prefixes, sometimes, can be left out. What about object naming conventions? You left those out and those are even more critical to the contemporary VFP application. What tells you more in code:
>
>>THISFORM.Main.ClientPage.Lastname.Value --- or ----
>>THISFORM.pgfMain.pagClientPage.txtLastName.Value
>
>.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.
>Well, naming conventions for object are no different than for variables. If you name your object right, you won't need them:
>
>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?
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.
>But I have no objection to use:
>Txt prefix for Textboxes
>Cmb prefix for comboboxes
>
>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.
>Even the VFP team seem to have no exact standpoint on this. Subclassed object have no objecttype prefixes oposed to the standard baseclasses.
>
VFP imposes no standards, a name is a name is a name as far as VFP is concerned - there's no magic in how a name is formed, at least not that's used in any way, shape or form by VFP, with the exception of avoiding certain reserved keywords (documented fully in the VFP online help) that may give VFP's parser fits, especially when macro expansion is used. So the value of naming conventions isn't one of code efficiency, but of programmer efficiency, in much the same way that adequate, complete and consistent commenting of code increases programmer efficiency. The standard helps the poor schmuck trying to fix or enhance the code, not VFP.
