Hi John,
MS clearly agrees with you on this one, but I believe Steven Black is with me on the Count idea. I feel free to enlist his support when we agree. :-)
Sometimes a prefix is helpful and sometimes it's not. I can say it and I do...and I think so do you. Do you use a prefix for all names? I can't remember, but certainly there are many who agree that it's unnecessary for fieldnames and some add in properties. I understand that it's perhaps a consistency thing still, but isn't it just a matter of where you draw the line?
Folks use naming conventions to rate programming skills. They think it looks professional— I'm told. I prefer that programmers concentrate on the names they give things because if those names are compelling, it makes using them a lot easier. Many will say you can do both, but then you end up with dStartDate, and nNumberOfMatches, which just seems too redundant, too silly, and too unprofessional for me.
Charlie

>I can understand that there could be use of a general "Count" property in some indirect addressing circumstances, but using Count after the singular name of the collection that is being counted just makes too much sense to me. Pages(PageCount) ... Forms(FormCount) ... and this naming strategy is carried over to virtually all other programmable MS products.
>
>As to arrays, this demonstrates the compelling need for standards. You can't say "sometimes a prefix is helpful" and then arbitrarily use object or var or array prefixs. Things get even more confusing.
>