count vs length vs size in a collection

FWIW (and that's vanishingly close to nothing), I prefer 'Count' because it seems to indicate that it's going to return the number of elements/items in the collection pretty unambigously.

When faced with the terms 'Length' or 'Size' I'm often left wondering for a moment (or even being forced to re-read documentation) whether the damn thing is going to tell me how many elements are in the colection or how many bytes the collection is consuming. This is particularly true for collections that are intended to be contingous like arrays or strings.

But no one who was responsible for the naming conventions used by the Java, BCL/.Net, or C/C++ standard frameworks/libraries bothered to ask me, so you're all stuck with whatever they came up with.

If only I were much smarter than I am and was named Bjarne, all of you might be spared the misery...

Of course, back in the real world, you should try to stick with whatever naming convention is used by the language/platform you're using (eg., size() in C++). Not that this seems to help you with your Array.Length dilemma.

Length() tends to refer to contiguous elements - a string has a length for example.

Count() tends to refer to the number of elements in a looser collection.

Size() tends to refer to the size of the collection, often this can be different from the length in cases like vectors (or strings), there may be 10 characters in a string, but storage is reserved for 20. It also may refer to number of elements - check source/documentation.

Capacity() - used to specifically refer to allocated space in collection and not number of valid elements in it. If type has both "capacity" and "size" defined then "size" usually refers to number of actual elements.

I think the main point is down to human language and idioms, the size of a string doesn't seem very obvious, whilst the length of a set is equally confusing even though they might be used to refer to the same thing (number of elements) in a collection of data.