Always an interesting topic, the evolution & philosophy of naming conventions :)

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

That actually is my former philosphy :) But I've seen too much code done by others by now, and many are lazy or just plain not too good at variable naming, so I've evolved to deciding the prefix convention for locals (I'm not including properties here, I agree with you on that) is always a good thing, but no 'l', of course.

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

There is no longer any need for 'm.', so why use it? Using the table prefix for fields is our standard, makes code readable, and obviates the need for 'm.' I don't know about you, but I no longer have one line of code that requires an 'm.' in anything I've coded since buffering came along...

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

I'm a former name-convention rebel, myself, as I said, so I've been there :) But I've found a good standard compromise that I'm content with, and I'm convinced is good policy for our agency. But it's been an evolutionary process over many years, and is subject to change due to technological changes, like the dumping of special prefixes for local, public, private...