Hi Bruce,
I've snipped some of your comments.
>There are still some situations where it's difficult for the variable name to indicate what Type it is, so for some cases, a prefix will help identify type. Then the next step, of course, is that you have to be consistent, so all variables get a Type prefix. At least where I work, all code must be considered possible legacy code for someone else to have to read at a future date, so a convention is important for that, as well as current developers.

I agree that coming up with a good descriptive variable/property is hard sometimes, so there may be times when you need a prefix. However, that should be the exception. And for that very reason, it should not be the rule! The general rule is name it well--the exception is--use some abbreviation 'cause I can't figure out how to indicate type with English.

>I strongly dislike the 'm.', it's a relic of the past.
'm.' has never been more relevant. Now that we have all kinds of objects running around doing their appointed task, you can't possibly keep track everyone's field names/variable conflicts. When VFP has to locate a pointer it helps it to know if you want a memory variable/object reference--not a alias.fieldname. As Val Karpov pointed out to me, 'm.' where needed, is faster that no 'm.' The more tables open and the more field names per table, the faster it is--up to 175% faster with 250 tables.

>These are true, for sure. But a team should set and document standards, and I don't usually have trouble reading code that has a solid standard to it, once I decipher what the standard is :)
I am reminded of Zen and the Art of Motorcycle Maintanence where the author goes crazy trying to define quality. Part of the answer was to care about the job--which I think we all do. My problem is it's so easy to contentrate on the convention prefixes and think we are promoting good code.