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

Actually, I'd probably call it frm_absSecurityProcessingServer, since it's meant to be an abstract class that's never instantiated in and of itself. Processing would be generic methids related to generic security objects, as opposed to enforcement, encryption, etc. If anything is ambiguous, it's security; am I validating user identity, privileges, etc.

If anything would be confusing, SecurityServerForm would be, since its behavior is anything but form-like, and it can't ever be instanciated.

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

Of you document a standard, then you can bring someone on and let them read the standard. The advantage to the standard is not just that it gives information to those who know it, it provides a set of rules to allow someone coming in off the street come up to speed that much quicker. Consistency aids in the adaptation process.

>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.
>
You and I differ here in an unreconcilable fashion; naming conventions provide useful information an an easily interpretable and consistent fashion. This makes the next guy's job that much easier, as well as my own. Using naming conventions doesn't change the requirment for meaningful names, and you can construct meaningful names with or without conventions and standards. It's much easier to walk in cold if there are standards, even if they differ from what you normally use.