Hi Kevin,

What you have written is true alright, but I really did not see these factors as the main thrust of Walter's message (though I will agree that most respondents seemed to have interpreted it as a "challenge" rather than a question).

Towards the end you write "Some companies insist that developers adhere. . .". What is missing is the same companies should constantly be on the lookout for areas which can be improved and this should include naming conventions. I can really see no legitimate reason to "stick" to anything, including a specific naming convention, when something better comes along. And there should be no doubt that VFP3's sudden allowing of 128 characters permits a vast array of opportunities that were not previously available.

Each company might well choose to do theirs differently, but the point is that they should surely change them in light of the new capability.

There is also something near-universal that programmers feel compelled to abbreviate everything. I have seen some programming where not a single complete English word appears as a user-selected name regardless of the capabilities of the programming language. This is silly, though I will agree that at one time is was about the only way to go. It is no longer, yet it is still most widely practised. Just a (bad) habit in my opinion, and one needing dialogue like this in hopes of getting it a re-think.

While I'm at it let me expose that the VFP "standards" (suggested by MS in the VFP documentation) appears to place form over substance. I say this because they specified "pag" for a page of a pageframe when the English language already has "pg" which is perfectly good and well understood as meaning "page". But MS seems to feel that everything being 3 characters for these prefixes is more important than comprehension.

Regards,

Jim N

>Lets keep in mind that naming conventions serve
>to keep unity throughout the style of programming
>in a project, not to make life easier for the
>programmer.
>
>Naming conventions may take a second more per
>command to type, but when you are developing shared
>components, or working on a development team, it
>sure makes life a little easier if you know ahead
>of time how data types are identified per variable.
>And it makes adding a field to a table, or a method
>to a form easier if you have an idea what the field
>or method name should look like.
>
>And if you have agreed before development starts that
>methods, properties and fields will be named according
>to a certain structure, than it's less likely mistakes
>will be made by other programmersm because they will
>come to expect certain formats, instead of opening code
>and seeing "gn" one time and "pn" the next when looking
>for a global/public numeric variable.
>
>Some companies insist that developers adhere to coding
>and naming standards to protect themselves. It saves
>maintenance time later on if the code is documented
>according to a company standard.
>
>So keep in mind that learning to code that way now should
>result in time (and sanity) saved later.
>
>Thats my humble opinion