Hi Bruce,
>Always an interesting topic, the evolution & philosophy of naming conventions :)
I always wonder why folks get so adamant about supporting cFirstName and the like, co-programmer Bruce, or cpgBruce.
>
>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 don't see why lazy programmers or bad names should convince you to...wait a minute. I guess I do see. Since we can't define quality programming, quality naming, etc., we'll adopt a standard that we can evaluate it more easily. That way the manager types won't have to actually know anything—just look for the standard. Put in the right prefixes and it looks good. (I'm overstating, I know. I don't know why I react so adamantly either)

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

I just don't understand this. As Christof Lange has stated, if you are going to write code for many situations, you must render your variables and object reference non-ambiguous. Note the comments in MS's GenDBC.PRG. I have never understood why a prefix would somehow negate fieldname conflicts. Fields are named nUsed, meaning, of course, NursesUseSyringesDaily, that could easily conflict.

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

Yep.
Charlie