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.

>I may be stretching it a bit, but so are you. Yes, if an object holds multiple collections, Count is ambiguous. But a PageFrames sole responsibility is to manage a collection of pages--likewise an OptionGroup for buttons. The Count could be called PrimaryItemCount, I would simply argue for a specific name for a specific abstract concept, in this case, the number of items contained.
>I have read your other posts and you have good company in your argument for naming conventions. In my Fox Talk article, "A cRose by any other oName", Steven Black wrote in the succeeding issue that naming conventions were still a good thing. He said something to the effect that it no prefixes looked unprofessional. To my mind this shows the weakness of the position, but others find youall's points conpelling. Steven Black did make note that the convention for an array, a starting 'a', was good in that
>myvar = '' when it's an array really means

>FOR m.x TO ALEN(myvar,1)
>   myvar = ''
>ENDFOR

>and I agreed that an arrays need some help to be clear as to what is happening.
>
>
>
>>Hi Charlie ----
>>
>>>I like polymorphistic names, so I think MS erred by naming things like PageCount, FormCount, ButtonCount. It's a PageFrame! It has a count! The property should be Count. If something has a Name, I call it Name, not CustName. It's in the Customer table, so that's the context.
>>
>>I personally agree with the customer table argument, but several server database design tools would disagree.
>>
>>OTOH, it's PageCount, FormCount, etc. because it's a reference to a collection of the root object, NOT the root object itself. Therefore, PageFrame.Count would be non-sensical. Is this a count of PageFrames? Is this the Count number for this PageFrame? And what about objects that hold multiple collections...they can't all be Count, can they?