Ed,

>We then get into the issue of what do we do when we use a thing in a way not part of its original type. If I build an abstract base class for implementing in-process servers that performs security validation based on the Form class (perhaps because I needed a private data session before VFP6 SP3 came out with the Session) but never has a visible aspect, should the class name be BaseSecurityProcessingServerForm, or frmBaseSecurityProcessingServer?

I would choose for the former, you would choose probably for the latter. Hmmm. The Base is referring to a class that is never directly used, but only for subclassing right ? I never tend to use that strategy...... If it doesn't, what does Base mean ? Processing... Isn't a server almost always used for processing something ? If so why use the word processing ? Would SecurityServerForm not say it all ?

B.T.W. did you read the article I gave the reference to ? I find it refreshing and gives some good tips regarding variable and classnaming ?

But that's not the issue. You (and also me in the past) choose to use naming conventions. You and a whole lot of other developers are comfortable with it. That's fine. And as long as no other people with no experience of your naming convention style, it will not lead to decreased maintainability. I admit when i would decide to drop all naming conventions I'll defenitely have a hard time the first few months.

But when I look at the future and ask myself: have naming conventions a future, given all the avialable technology ? I don't think so. I see no point in teaching naming conventions to new developers (unless they will maintain a lot of code containing this). For a lot of us it seems to be too late: we carry the past with us.

Walter,