Let me prefix my statements with "Standards are whatever naming technique makes the most sense to you and your company to make development and support as easy as possible."

With that being said, there are multiple 'standards camps' in not just VFP but other languages as well. Yes, one of the earlier standards was to prefix the variable name with a two character table identifier. I'm not sure if he originated it, but I first saw that with George Goley in the FoxPro DOS days of the earlier 90's. Yes, it told you which table the variable belonged to. It even prevented accidental copies of data (via SCATTER and GATHER). It just doesn't define the variable type which if you are careful now that you have more than just 10 characters you can easily do. However...

I've seen more than enough poorly named variables, or variable names that implied one variable type but were really another. I've seen variable names with the word DATE in them that were actually character fields, ID fields that were sometimes numeric and sometimes character (with the program using STR() functions to create relations). I've also worked on programs that still today retain 10 character names and thus have very cryptic meanings. More times than I care to count I've guessed wrong at the variable type and gotten the 'Type Mismatch' error. This may be because I'm looking at someone else's code. If I write the code, I probably 'know' what the variable types are, but will someone else? Will I still remember 6 months from now?

Honestly, I've switch from no standards many years ago, to the two character prefix that identifies the table, to the current single character prefix for table fields and a two character prefix for memory variables where the first character identifies the scope of the variable. While that works for me, you and your company will have to decide what makes sense for you.

One last point, don't switch standards mid-project. Think carefuly about what your standards needs are first. Then as a test, pick a standard and implement it for a new project, one that does not have to integrated with other systems or data files. Don't be afraid if you tweak the standard for your specific needs as long as all your co-workers agree to the tweak. And especially, don't switch standards with each new project. Prefixing strings with an 's' in one project to create variable 'sRap' and then switching to prefix with 'c' in another project is just 'cRap'. And furthermore, it is more confusing than no standard at all.

Mike Antonovich

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