Kevin,

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

What's wrong with keeping unity in code without naming conventions ? Thoug I agree with your statement that it does not help the programmer, you 'll find that whole tribes here religious believe in it.

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

Withing a strict typed language like C, C++, I would say you're right. But since VFP doesn't care if you don't declare variables, and you can put anything in it, Why ?

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

Well, these arguments are alread discussed in this thread. I didn't ment to say that you should have no standard for naming variable or objects. I really ment to say that naming conventions (like hungarian) can be left out. For a great reference: http://www.oma.com/ottinger/Naming.html#Pronounceable

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

See the above

>So keep in mind that learning to code that way now should
result in time (and sanity) saved later.

Well, I think using no naming conventions regarding variables and object are just an improvement rather than a limitation.

Walter