liczba vs długość vs rozmiar w kolekcji

Korzystając z wielu języków programowania i bibliotek, zauważyłem różne terminy określające całkowitą liczbę elementów w kolekcji.

Najczęstszym wydają się być length, counti size.

na przykład.

array.length
vector.size()
collection.count

Czy jest jakiś preferowany termin, którego należy użyć? Czy zależy to od rodzaju kolekcji? to znaczy. zmienny / niezmienny

Czy wolisz, aby była to właściwość, a nie metoda?

Length() ma tendencję do odwoływania się do ciągłych elementów - na przykład łańcuch ma długość.

Count() zwykle odnosi się do liczby elementów w luźniejszej kolekcji.

Size() zwykle odnosi się do rozmiaru zbioru, często może się on różnić od długości w przypadkach takich jak wektory (lub łańcuchy), ciąg może składać się z 10 znaków, ale pamięć jest zarezerwowana dla 20. Może również odnosić się do liczby elementy - sprawdź źródło / dokumentację.

Capacity()- używany do określania przydzielonego miejsca w kolekcji, a nie liczby ważnych elementów w nim. Jeśli typ ma zdefiniowane zarówno „pojemność”, jak i „rozmiar”, wówczas „rozmiar” zwykle odnosi się do liczby rzeczywistych elementów.

Myślę, że główny punkt sprowadza się do ludzkiego języka i idiomów, rozmiar ciągu nie wydaje się zbyt oczywisty, podczas gdy długość zestawu jest równie zagmatwana, mimo że mogą być użyte do odniesienia się do tego samego (liczba elementów ) w zbiorze danych.

FWIW (i to znikomo prawie nic), wolę „Count”, ponieważ wydaje się wskazywać, że zwróci liczbę elementów / elementów w kolekcji dość jednoznacznie.

W obliczu terminów `` długość '' lub `` rozmiar '' często zastanawiam się przez chwilę (lub nawet jestem zmuszony do ponownego przeczytania dokumentacji), czy ta cholerna rzecz powie mi, ile elementów jest w kolekcji lub jak wiele bajtów zużywa kolekcja. Jest to szczególnie prawdziwe w przypadku kolekcji, które mają być ciągłe, jak tablice lub ciągi.

Ale nikt, kto był odpowiedzialny za konwencje nazewnictwa używane przez standardowe frameworki / biblioteki Java, BCL / .Net lub C / C ++, nie zadał sobie trudu, aby mnie o to zapytać, więc wszyscy utknęliście z tym, co wymyślili.

Gdybym tylko był znacznie mądrzejszy ode mnie i został nazwany Bjarne, wszyscy mogliby uniknąć nieszczęścia ...

Oczywiście w prawdziwym świecie powinieneś spróbować trzymać się dowolnej konwencji nazewnictwa używanej przez język / platformę, której używasz (np. size()W C ++). Nie żeby to wydawało się pomagać w Array.Lengthrozwiązywaniu dylematów.

Terminy są nieco zamiennie, chociaż w niektórych sytuacjach wolałbym jeden nad drugim. Zwykle możesz uzyskać najlepsze wykorzystanie, jeśli się zastanowisz. Jak opisałbyś ustnie długość / rozmiar / liczbę tego elementu innej osobie?

length()oznacza, że ​​element ma długość. Sznurek ma długość. Mówisz, że „ciąg ma 20 znaków”, prawda? Więc ma długość.

size()oznacza, że ​​element ma rozmiar. Np. Plik ma rozmiar. Mówisz „ten plik ma rozmiar 2 MB”, prawda? Więc ma rozmiar.

To powiedziawszy, sznurek może mieć również rozmiar, ale spodziewałbym się tutaj czegoś innego. Np. Łańcuch UTF-16 może mieć długość 100 znaków, ale ponieważ każdy znak składa się z dwóch bajtów, spodziewałbym się, że rozmiar będzie wynosił 200.

count()jest bardzo nietypowe. Objective-C używa count dla liczby elementów w tablicy. Można się spierać, czy tablica ma długość (jak w Javie), ma rozmiar (jak w większości innych języków) lub ma liczbę. Jednak rozmiar może być ponownie rozmiarem w bajtach (jeśli elementy tablicy są 32-bitowe, każdy element ma 4 bajty) i długości ... Nie powiedziałbym, że "tablica ma 20 elementów", to brzmi raczej dziwnie mnie. Powiedziałbym, że „tablica ma 20 elementów”. Nie jestem pewien, czy count wyraża to bardzo dobrze, ale myślę, że count jest tutaj krótką formą dla elementCount()i to znowu ma znacznie więcej sensu w przypadku tablicy niż length () lub size ().

Jeśli tworzysz własne obiekty / elementy w języku programowania, najlepiej jest używać innych podobnych elementów, ponieważ programiści są przyzwyczajeni do uzyskiwania dostępu do żądanej właściwości za pomocą tego terminu.

Myślę, że Count jest najbardziej oczywistym terminem, którego należy użyć, jeśli szukasz liczby elementów w kolekcji. Powinno to być nawet oczywiste dla nowych programistów, którzy nie są jeszcze szczególnie przywiązani do danego języka.

Powinna to być własność, bo tym właśnie jest: opis (czyli własność) kolekcji. Metoda sugerowałaby, że musi coś zrobić z kolekcją, aby uzyskać liczbę elementów, a to po prostu wydaje się nieintuicyjne.

Hmm ... nie użyłbym rozmiaru. Ponieważ można to pomylić z rozmiarem w bajtach. Długość - może mieć jakiś sens w przypadku tablic, o ile mają one używać kolejnych bajtów pamięci. Chociaż ... długość ... w czym? Hrabia jest jasny. Ile elementów. Użyłbym count.

O właściwości / metodzie użyłbym własności, aby oznaczyć, że jest szybka, i metody, aby oznaczyć, że jest wolna.

I najważniejsze - trzymałbym się standardów języków / bibliotek, których używasz.

Dodawanie do odpowiedzi @ gbjbaanb ...

Jeśli „właściwość” oznacza publiczny dostęp do wartości, powiedziałbym, że „metoda” jest preferowana po prostu w celu zapewnienia hermetyzacji i ukrycia implementacji.

Możesz zmienić zdanie co do countelementów lub jak je utrzymywać count. Jeśli jest to właściwość, utkniesz - jeśli zostanie uzyskana za pomocą metody, możesz zmienić podstawową implementację bez wpływu na użytkowników kolekcji.

W Elixirze istnieje jasny schemat nazewnictwa powiązany z różnymi typami w języku.

Podczas „zliczania” liczby elementów w strukturze danych Elixir również kieruje się prostą zasadą: nazwa funkcji następuje, sizejeśli operacja jest w stałym czasie (tj. Wartość jest wstępnie obliczona) lub lengthjeśli operacja jest liniowa (tj. długość zmniejsza się wraz ze wzrostem wkładu).

Dla mnie to trochę tak, jakby zapytać, czy „każdy” jest lepszy niż „dla każdego”. Zależy to tylko od języka / frameworka.

Powiedziałbym, że zależy to od konkretnego języka , którego używasz i klas . Na przykład w języku C #, jeśli używasz Array, masz Property Length, jeśli masz coś, co dziedziczy po IEnumerable, masz rozszerzenie Method Count (), ale nie jest to szybkie. A jeśli odziedziczyłeś po ICollection, masz Property Count.