コレクション内のカウントvs長さvsサイズ

多くのプログラミング言語とライブラリを使用していることから、コレクション内の要素の総数に使用されるさまざまな用語に気づきました。

最も一般的なのは、ように見えるlength、countとsize。

例えば。

array.length
vector.size()
collection.count

使用すべき好ましい用語はありますか？コレクションの種類によって異なりますか？すなわち。可変/不変

メソッドではなくプロパティであるという好みはありますか？

Length() 隣接する要素を参照する傾向があります-たとえば、文字列には長さがあります。

Count() より緩いコレクションの要素数を参照する傾向があります。

Size() コレクションのサイズを参照する傾向があります。これは、ベクター（または文字列）のような場合には長さと異なる場合があります。文字列には10文字がある場合がありますが、ストレージは20のために予約されています。要素-ソース/ドキュメントを確認してください。

Capacity()-コレクション内の割り当てられたスペースを具体的に参照するために使用され、その中の有効な要素の数ではありません。タイプに「容量」と「サイズ」の両方が定義されている場合、「サイズ」は通常、実際の要素の数を指します。

主なポイントは人間の言語とイディオムにあると思いますが、文字列のサイズはそれほど明白ではないように見えますが、セットの長さは同じもの（要素の数） ）データのコレクション内。

FWIW（そしてそれはほとんど何もないことに近い）、私は 'Count'を好む。というのは、コレクション内の要素/項目の数をかなり明確に返すことを示しているようだからです。

「長さ」または「サイズ」という用語に直面すると、コレクションに含まれている要素の数やその方法が何であるかを教えてくれるのかどうか、ちょっと疑問に思うことがよくあります（またはドキュメントの再読を強いられます）。コレクションが消費しているバイト数。これは、配列や文字列のように偶然であることが意図されているコレクションに特に当てはまります。

しかし、Java、BCL / .Net、またはC / C ++の標準フレームワーク/ライブラリで使用されている命名規則に責任を負う人は誰も私に尋ねる必要はありませんでした。

私だけが私よりもずっと賢く、Bjarneと名付けられたとしたら、皆さん全員が悲惨さを免れるかもしれません...

もちろん、現実の世界に戻ると、使用している言語/プラットフォーム（size()C ++など）で使用されている命名規則に固執する必要があります。これがあなたのArray.Lengthジレンマにあなたを助けるようであるというわけではありません。

これらの用語は多少互換性がありますが、状況によっては、どちらか一方を優先する場合があります。通常、この要素の長さ/サイズ/数を他の人に口頭でどのように説明するかについて考えれば、最高の使用法を得ることができますか？

length()要素が長さを持つことを意味します。文字列には長さがあります。あなたは「文字列は20文字の長さです」と言いますよね？だから長さがあります。

size()要素にサイズがあることを意味します。たとえば、ファイルにサイズがあります。「このファイルのサイズは2 MBです」と言いますよね？なのでサイズがあります。

とはいえ、文字列にもサイズを設定できますが、ここでは別のものが期待されます。たとえば、UTF-16文字列の長さは100文字ですが、すべての文字は2バイトで構成されているため、サイズは200になるはずです。

count()非常に珍しいです。Objective-Cは、配列の要素数にcountを使用します。配列が（Javaのように）長さを持っているか、（他のほとんどの言語のように）サイズを持っているか、またはカウントがあるかを議論する人がいるかもしれません。ただし、サイズはバイト単位のサイズ（配列の項目が32ビットintで、各項目が4バイトの場合）と長さになる可能性があります...「配列は20要素の長さ」とは言えません。私。「配列には20個の要素がある」と言います。countがそれを非常にうまく表現しているかどうかはわかりませんが、ここではcountは短い形式でelementCount()あり、これもlength（）やsize（）よりも配列の方がはるかに意味があると思います。

プログラミング言語で独自のオブジェクト/要素を作成する場合、プログラマーはその用語を使用して目的のプロパティにアクセスするのに慣れているため、他の同様の要素を使用するのが最善です。

カウントは、コレクション内のアイテムの数を探す場合に使用する最も明白な用語だと思います。これは、特定の言語にまだ慣れていない新しいプログラマにとっても明らかです。

そして、それはそれが何であるかということであるプロパティであるべきです：コレクションの説明（別名プロパティ）。メソッドは、アイテムの数を取得するためにコレクションに対して何かを行う必要があることを意味しますが、これは直感的ではないように見えます。

うーん...私はサイズを使用しません。これはバイト単位のサイズと混同される可能性があるためです。長さ-配列がメモリの後続のバイトを使用することが想定されている限り、配列に意味があります。でも...長さ...何で？カウントは明確です。要素の数。カウントを使用します。

プロパティ/メソッドについて、私はプロパティを使用して高速であることをマークし、メソッドを使用して低速であることをマークします。

そして、最も重要なことは、私はあなたが使用している言語/ライブラリの標準に固執することです。

@gbjbaanbの回答に追加しています...

「プロパティ」が値へのパブリックアクセスを意味する場合、「メソッド」はカプセル化を提供し、実装を隠すためだけに好まれると思います。

どのようにcount要素を管理するか、それをどのように維持するかについて気が変わるかもしれませんcount。プロパティの場合、行き詰まっています。メソッドを介してアクセスする場合は、コレクションのユーザーに影響を与えることなく、基盤となる実装を変更できます。

エリクサーには、言語のさまざまなタイプに関連付けられた明確な命名方式があります。

データ構造内の要素の数を「数える」とき、Elixirも単純な規則に従います。size操作が一定時間内にある場合（つまり、値が事前計算されている場合）、または length操作が線形である場合（つまり、計算中）入力が大きくなるにつれて、長さが遅くなります）。

私にとって、これは「foreach」が「for each」よりも優れているかどうかを尋ねるようなものです。言語/フレームワークに依存します。

それはあなたが使っている特定の言語とクラスに依存すると私は言うでしょう。たとえばc＃では、配列を使用している場合はプロパティの長さ、IEnumerableから継承するものがある場合は拡張メソッド Count（）がありますが、高速ではありません。ICollectionから継承した場合は、プロパティカウントがあります。