I prefer to use these naming conventions because it is pretty much the standard for Microsoft's languages. Since I use more than one language, I prefer to have a standard naming convention for all. These conventions within this white paper work just fine for me. If another programmer has any question about a variable, all he/she has to do is look at the documentation for that particular language.


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