>Ed,
>
>>All you've done is moved the reference from prefix to suffix. That's fine, but it's no different a technique, except for how you visually process the symbol - you have to read the entire name and begin a cognitive process, since it's at the end of the "word" and the length is not consistent or necessarily small. Prefixes can be scanned and reacted to before cognitive analysis of the name takes place, and are of a small and relatively consistent size and formation.
>
>I Also removed the abbreviations in the name, and this is one of the major advantage in my POV. Like a lot of people I have some difficulties to read abbreviations in for example: the Adds in the newspapers. One of the first lessons i got when I went to universaty was to avoid abbreviation as much as possible because they can be hard to read for another programmer. That this implies that variablename get longer is by no means a reason to give in on readability.
>

I understand, but again, the argument in favor of the prefix isn't reading all the code to understand the module, but identifying the intended scope and type of the thing outside its usual context in code. This is where the prefix pays off, at least for me - it's a quick reminder in the debugger about the scope and data type as much (or more than) telling me what it's intended to do when reading the method or function for comprehension. I still advocate the use of long, meaningful names for things to aid me in fathoming the process I've implemented. I just like the idea of a quick clue in a consistent location that serves as a flag when I make a mistake and have to trace through the code that doesn't require me to read and digest the name to get type and scope of what I'm looking at.

Even in ads in the paper, good, standard abbreviations help - I can filter out anything that says 2BR if I need 3 bedrooms. As long as the abbreviation is consistent, it serves a good purpose; life gets much more difficult if in addition to BR, I have to look for B/R, Bdrm, etc. The naming standard helps identify what you're looking at.

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?