28

In C# for example, arrays have Length property. But other collection types like lists, etc. have Count property. Is there a reason why these two are different? If so I would like to know.

Arunster
  • 407
  • 4
  • 6
  • 4
    I can't find my Lippert-whistle, so I don't think we'll get a good answer today :( – MetaFight Aug 26 '15 at 09:48
  • 4
    Just a wild guess, as I have no inside knowledge on how the CLR was designed: the details of how arrays work were specified before the collection types. Calling the property Length is the most natural name for it, and as there wasn't a preexisting standard to conform to, so this is what the designer of arrays chose to use. Then the collections were specified afterwards, but Length isn't appropriate for some collections (it implies linearity, so for unordered collections it is not a reasonable name) so Count was chosen as more logically consistent. – Jules Aug 26 '15 at 10:47
  • 4
    I guess this former [stackoverflow post](http://stackoverflow.com/questions/300522/count-vs-length-vs-size-in-a-collection) has the right answer. – Doc Brown Aug 26 '15 at 11:27
  • 1
    A little more serious than MetaFight's comment, but the same meaning. The only people who could possibly answer this question definitively is the .Net debt team. – RubberDuck Aug 26 '15 at 11:43
  • 6
    @MetaFight: I recently recorded a series of educational videos and at one point I mention that I have no idea why the designers used both length and count. It has always struck me as bizarre. The comment from Jules above seems plausible. – Eric Lippert Aug 26 '15 at 16:55
  • 3
    Meta note - I have cast the 5th VTC as I don't believe this question can be definitively answered. The existing answer is a solid and plausible answer, but it is not backed with evidence. Likewise, Lippert's comment leads me to think that no one knows the answer as it could have been due to an oversight as opposed to a conscious decision. –  Aug 26 '15 at 17:27
  • cuz they knew they were going to implement Count() in LINQ rite – moarboilerplate Aug 27 '15 at 01:52
  • @EricLippert Well, thanks for your input anyway. It seems to have been conclusive enough to determine the fate of this question :) – MetaFight Aug 27 '15 at 07:35

1 Answers1

37

They are named differently because semantically they are quite different:

A collection's Count is the number of items currently stored in it and can potentially change over time.

An array's Length is the maximum number of items it can hold (it will have a length of 10 even if you haven't stored that many items in it) and is immutable.

Example:

If I have a bucket that can fit a maximum of 100 balls in it it has a Length of 100. If I put 50 balls into it it then it has a Count of 50.

If I add 10 more balls the Count becomes 60 but the Length is still 100. In order to change the Length I need to get a different bucket.

Array probably uses the word Length because under the hood it's allocating a contiguous block (a length) of memory based on the capacity multiplied by the item size. Although the fact that the List class uses "Capacity" for a similar (though mutable) concept suggests array may use the word "Length" for historical reasons.

combinatorics
  • 739
  • 1
  • 7
  • 8
  • 13
    A `T[]` with a length of N always stores exactly N values of type `T`. Semantically, not all of those values may be meaningful (they might be `null` for example), but they exist. This is different from the usual meaning of capacity (as used by `List` for example). You're right that `Count` can change while `Length` can't. Then again, nothing mandates that `Count` will, in fact, change. It is also used for immutable collections. –  Aug 26 '15 at 11:41
  • @delnan oh dear. didn't realise the word Capacity was already used in C# like this. I've accidentally overloaded it. Thanks for pointing this out. I'll update my answer to clarify. – combinatorics Aug 26 '15 at 11:47
  • Difference between Capacity and Length is - Capacity might change over the life-cycle of the object, while Length always stays the same. If I see a Length property on the object, I'd assume it's "hard" maximum number (or the border / index), while if I see Capacity property, I'd assume it's "soft" maximum number which I should only check against if I'm concerned with performance. – StupidOne Aug 26 '15 at 13:27
  • @StupidOne: If you go that route, then any array should also have a `count`-property. – Deduplicator Aug 26 '15 at 13:49
  • @StupidOne When delnan first commented I thought it might be the case that Length was synonymous with "fixed capacity" but I found that the StringBuilder class didn't fit that usage. StringBuilder has a Length property that can grow as things are appended, shrink as things are removed, and can even be manually set! – combinatorics Aug 26 '15 at 14:04
  • 1
    Damn StringBuilder... in stricter Languages like Vigil the StringBuilder class would have been properly punished for breaking convention https://github.com/munificent/vigil – Falco Aug 26 '15 at 14:57
  • @combinatorics: I find it odd that `StringBuilder` includes a property setter for length, but not content; indeed, I don't know any way to set a string builder's concent except by clearing it and appending the content. I would think it would have been more natural for StringBuilder to have a read-only `Length` property but include `Truncate`, `Pad`, and `PadOrTruncate`, methods to set the length (with the methods other than `Pad` including a parameter for the padding character). I'd use `Length` because its purpose is to return the Length of the currently-encapsulated string. – supercat Aug 26 '15 at 16:22