>>Microsoft has a good white paper on Visual FoxPro naming conventions for variables, objects, constants, windows and table field names. It is a good reference paper. It can be found at:
>>
>>http://support.microsoft.com/support/kb/articles/Q129/9/77.asp
>
>PMFJI but I think that naming conventions are more a waste of time in the methods described in that M$ article.
>
>dDuedate why not DueDate?
>
>cCity, cSt, cZip, cPhone, cCell
>
>It's just a waste of a character.
>
>iid? uid? is it an interger ID or an Unknown ID or Interger ID.
>
>laCustListArray
>
>Does anyone ever do a Public anymore? If not why should I disclose that everything is local.
>
>The name says it all. Go look at all the help examples and they retype array in all their array names.
>
>Just my 2 cents worth here.
>
>Now If a comapny set standards like table filed names have the first 2 digits defining the table they reference, that would be somthing I would agree with.
>
>SHordnum = Sales Header order #
>SDlineno = Sales Detail line #
>SDqtyord = Sales Detail Qyt ordered
>SD_ID = Sales header Primary Key
>SD_SHK = Key to Sales header
>SH_CUK = Key to customer table
>
>Now in a join my primary keys are unique in name and that is something that is usefull.
>
>Where in the example below:
>Sele Cust.iid, customer.cCompany, SOHeader.iid ..... ;
>from VES!Cust inner join VES!SOHEADER ;
>ON Cust.iid = SOheader.iid ;
>where ... ;
>
>This will always give iid_a, iid_b in a return set and it's a RPITA to adapt the rightful keys to the proper tables in a view.
>
>Thses are standards that have lived for years in other languages from COBOL days and have never been adopeted in FP any flavor. Not that I want to adopt other joys of cobol mind you!!!
>
>__Stephen
>


The only field naming standards I use are for the primary key, which is always Table + Id, so for Employee.Dbf, it is EmployeeId. This field name is used in all tables that need a reference to the Employee.