FWIW here are a couple of things I recommend:

1. Get in the habit of using a one-character prefix to identify your data type. For example, cLastName, dBirthDate, nAmount, etc. (the so-called "Modified Hungarian Notation"). There are strong opinions on both sides of the issue about whether to use this or not, but in my own work I find it helpful when writing method code because it reminds me what data type I'm dealing with. It may seem awkward at first but it quickly becomes second nature.

2. Use camel case to increase the readability of your code. For example, cLastName is more readable than clastname. This makes no difference to VFP, which ignores case, and for that matter you can't even enter upper case for field names in the table designer. But you can name a field clastname and then refer to it as cLastName.

3. Avoid underscores to separate parts of a field or memvar name. IMO underscores just waste a character, which can make a difference when you're trying to stay within the ten-character length limit for field names in free tables. Use camel case instead.

4. Do be consistent with abbreviations, but avoid deliberately misspelled words like kount (for count) which may be hard to remember later on. And as Trey said, certainly avoid using VFP reserved words for field names.

HTH,
-Rick


>I have to create a bunch of new fields for several free tables. The previous names given to fields were not consistent. Guess I am looking for naming tips that might make my life easier for future modifications. I do understand
>
>1) be consistent with name given to a field. same field in two different tables should be given the same name
>
>2) be consistent with abbreviations.
>
>But should I ?
>
>3) Keep the field name to under 8 characters?
>
>4) Not use any special characters (such as the underscore)
>
>Any other tips that you can give me will be appreciated.
>
>Thanks
>
>Brenda