nombre vs longueur vs taille dans une collection

En utilisant un certain nombre de langages de programmation et de bibliothèques, j'ai remarqué divers termes utilisés pour le nombre total d'éléments dans une collection.

Le plus commun semble être length, countet size.

par exemple.

array.length
vector.size()
collection.count

Y a-t-il un terme préféré à utiliser? Cela dépend-il de quel type de collection il s'agit? c'est à dire. mutable / immuable

Y a-t-il une préférence pour que ce soit une propriété plutôt qu'une méthode?

Length() tend à faire référence à des éléments contigus - une chaîne a une longueur par exemple.

Count() tend à se référer au nombre d'éléments dans une collection plus lâche.

Size() tend à se référer à la taille de la collection, souvent cela peut être différent de la longueur dans des cas comme des vecteurs (ou des chaînes), il peut y avoir 10 caractères dans une chaîne, mais le stockage est réservé à 20. Il peut également faire référence au nombre de éléments - vérifier la source / la documentation.

Capacity()- utilisé pour désigner spécifiquement l'espace alloué dans la collection et non le nombre d'éléments valides qu'il contient. Si le type a à la fois «capacité» et «taille» définis, «taille» fait généralement référence au nombre d'éléments réels.

Je pense que le point principal est dû au langage humain et aux idiomes, la taille d'une chaîne ne semble pas très évidente, tandis que la longueur d'un ensemble est tout aussi déroutante même si elles peuvent être utilisées pour faire référence à la même chose (nombre d'éléments ) dans une collection de données.

FWIW (et c'est presque rien), je préfère «Count» car cela semble indiquer qu'il va renvoyer le nombre d'éléments / éléments de la collection sans ambiguïté.

Face aux termes `` longueur '' ou `` taille '', je me demande souvent pendant un moment (ou même obligé de relire la documentation) si la fichue chose va me dire combien d'éléments sont dans la collection ou comment beaucoup d'octets consommés par la collection. Cela est particulièrement vrai pour les collections qui sont destinées à être contingentes comme des tableaux ou des chaînes.

Mais personne qui était responsable des conventions de dénomination utilisées par les frameworks / bibliothèques standard Java, BCL / .Net ou C / C ++ n'a pris la peine de me le demander, vous êtes donc tous coincés avec tout ce qu'ils ont proposé.

Si seulement j'étais beaucoup plus intelligent que moi et que j'étais nommé Bjarne, vous pourriez tous être épargnés par la misère ...

Bien sûr, dans le monde réel, vous devriez essayer de vous en tenir à la convention de dénomination utilisée par le langage / la plate-forme que vous utilisez (par exemple, size()en C ++). Non pas que cela semble vous aider avec votre Array.Lengthdilemme.

Les termes sont quelque peu interchangeables, bien que dans certaines situations, je préfère l'un à l'autre. Habituellement, vous pouvez obtenir la meilleure utilisation si vous pensez à Comment décririez-vous la longueur / la taille / le nombre de cet élément verbalement à une autre personne?

length()implique que l'élément a une longueur. Une chaîne a une longueur. Vous dites "une chaîne contient 20 caractères", n'est-ce pas? Donc ça a une longueur.

size()implique que l'élément a une taille. Par exemple, un fichier a une taille. Vous dites "ce fichier a une taille de 2 Mo", non? Donc, il a une taille.

Cela dit, une chaîne peut aussi avoir une taille, mais je m'attendrais à autre chose ici. Par exemple, une chaîne UTF-16 peut avoir une longueur de 100 caractères, mais comme chaque caractère est composé de deux octets, je m'attendrais à ce que la taille soit de 200.

count()est très inhabituel. Objective-C utilise count pour le nombre d'éléments dans un tableau. On pourrait se demander si un tableau a une longueur (comme en Java), a une taille (comme dans la plupart des autres langages) ou a un nombre. Cependant, la taille peut à nouveau être la taille en octets (si les éléments du tableau sont 32 bits int, chaque élément fait 4 octets) et la longueur ... Je ne dirais pas "un tableau est long de 20 éléments", cela semble plutôt étrange. moi. Je dirais "un tableau a 20 éléments". Je ne sais pas si count l'exprime très bien, mais je pense que count est ici une forme courte pour elementCount()et cela a encore une fois beaucoup plus de sens pour un tableau que length () ou size ().

Si vous créez vos propres objets / éléments dans un langage de programmation, il est préférable d'utiliser tout autre élément similaire utilisé, car les programmeurs sont habitués à accéder à la propriété souhaitée en utilisant ce terme.

Je pense que c'est le terme le plus évident à utiliser si vous recherchez le nombre d'articles dans une collection. Cela devrait même être évident pour les nouveaux programmeurs qui ne sont pas encore particulièrement attachés à une langue donnée.

Et ce devrait être une propriété car c'est ce qu'elle est: une description (aka propriété) de la collection. Une méthode impliquerait qu'elle doit faire quelque chose à la collection pour obtenir le nombre d'éléments et cela semble tout simplement peu intuitif.

Hmm ... je n'utiliserais pas de taille. Parce que cela peut être confondu avec la taille en octets. Longueur - pourrait avoir un sens pour les tableaux, tant qu'ils sont supposés utiliser des octets de mémoire conséquents. Quoique ... longueur ... en quoi? Le compte est clair. Combien d'éléments. J'utiliserais count.

À propos de propriété / méthode, j'utiliserais la propriété pour marquer que c'est rapide et la méthode pour marquer c'est lent.

Et, le plus important - je m'en tiendrai aux normes des langues / bibliothèques que vous utilisez.

Ajout à la réponse de @ gbjbaanb ...

Si "propriété" implique un accès public à la valeur, je dirais que "méthode" est préférable simplement pour fournir l'encapsulation et pour masquer l'implémentation.

Vous pourriez changer d'avis sur la façon dont les countéléments ou comment vous les maintenez count. S'il s'agit d'une propriété, vous êtes bloqué - si elle est accédée via une méthode, vous pouvez modifier l'implémentation sous-jacente sans impacter les utilisateurs de la collection.

Dans Elixir, il existe en fait un schéma de dénomination clair qui lui est associé à travers les types dans la langue.

Lors du «comptage» du nombre d'éléments dans une structure de données, Elixir respecte également une règle simple: la fonction est nommée sizesi l'opération est en temps constant (c.-à-d. Que la valeur est précalculée) ou lengthsi l'opération est linéaire (c.-à-d. la longueur devient plus lente au fur et à mesure que l'entrée augmente).

Pour moi, c'est un peu comme demander si «foreach» vaut mieux que «for each». Cela dépend juste du langage / du cadre.

Je dirais que cela dépend de la langue particulière que vous utilisez et des classes . Par exemple, dans c #, si vous utilisez Array, vous avez Property Length, si vous avez quelque chose qui hérite de IEnumerable, vous avez l'extension Method Count (), mais ce n'est pas rapide. Et si vous avez hérité d'ICollection, vous avez Property Count.