recuento vs longitud vs tamaño en una colección

FWIW (y eso es casi nada), prefiero 'Count' porque parece indicar que va a devolver el número de elementos/elementos en la colección bastante inequívocamente.

Cuando me enfrento a los términos 'Longitud' o 'Tamaño', a menudo me quedo preguntándome por un momento (o incluso me veo obligado a volver a leer la documentación) si la maldita cosa me va a decir cuántos elementos hay en la colección o cuántos bytes está consumiendo la colección. Esto es particularmente cierto para colecciones que están destinadas a ser contingentes como matrices o cadenas.

Pero nadie que fuera responsable de las convenciones de nomenclatura utilizadas por los frameworks/bibliotecas estándar Java, BCL/. Net o C/C++ se molestó en preguntarme, así que todos están atascados con lo que se les ocurrió.

Si yo fuera mucho más inteligente de lo que soy y me llamaran Bjarne, todos ustedes podrían librarse de la miseria...

Por supuesto, de vuelta en el mundo real, usted debe tratar de atenerse a cualquier convención de nomenclatura es utilizado por el idioma / plataforma que está utilizando (por ejemplo., size() en C++). No es que esto parezca ayudarte con tu dilema Array.Length.

Los términos son algo intercambiables, aunque en algunas situaciones preferiría uno sobre otro. Por lo general, puede obtener el mejor uso si piensa en ¿Cómo describiría la longitud/tamaño/recuento de este elemento verbalmente a otra persona?.

length() implica que el elemento tiene una longitud. Una cuerda tiene una longitud. Dices "una cadena tiene 20 caracteres", ¿verdad? Así que tiene una longitud.

size() implica que el elemento tiene un tamaño. Por ejemplo, un archivo tiene un tamaño. Tú dices "este archivo tiene un tamaño de 2 MB", ¿verdad? Así que tiene un tamaño.

Dicho esto, una cadena también puede tener un tamaño, pero esperaría algo más aquí. Por ejemplo, una cadena UTF-16 puede tener una longitud de 100 caracteres, pero como cada carácter está compuesto de dos bytes, esperaría que el tamaño fuera de 200.

count() es muy inusual. Objective-C usa count para el número de elementos en un array. Uno podría argumentar si una matriz tiene una longitud (como en Java), tiene un tamaño (como en la mayoría de los otros lenguajes) o tiene un conteo. Sin embargo, el tamaño podría ser nuevamente el tamaño en bytes (si los elementos de la matriz son de 32 bits int, cada elemento es de 4 bytes) y la longitud... Yo no diría "una matriz tiene 20 elementos de largo", eso me suena bastante extraño. Yo diría que "una matriz tiene 20 elementos". No estoy seguro de si count expresa eso muy bien, pero creo que count es aquí una forma corta para elementCount() y que de nuevo tiene mucho más sentido para un array que length() o size().

Si crea objetos / elementos propios en un lenguaje de programación, es mejor usar cualquiera que sea el uso de otros elementos similares, ya que los programadores están acostumbrados a acceder a la propiedad deseada utilizando ese término.

Count Creo que es el término más obvio para usar si estás buscando el número de artículos en una colección. Eso incluso debería ser obvio para los nuevos programadores que aún no se han apegado particularmente a un lenguaje dado.

Y debería ser una propiedad ya que eso es lo que es: una descripción (también conocida como propiedad) de la colección. Un método implicaría que tiene que hacer algo a la colección para obtener el número de elementos y eso parece poco intuitivo.

Hmm...No usaría el tamaño. Porque esto podría confundirse con el tamaño en bytes. Longitud-podría tener algún sentido para los arrays, siempre y cuando se supone que utilicen los bytes consecuentes de memoria. Though...length...in ¿qué? El conteo está despejado. Cuántos elementos. Yo usaría count.

Acerca de property/method, usaría property para marcar que es rápido, y method para marcar que es lento.

Y, lo más importante - me apegaría a los estándares de los idiomas/bibliotecas que está utilizando.

Añadiendo a la respuesta de @gbjbaanb...

Si "property" implica acceso público al valor, yo diría que "method" es preferible simplemente para proporcionar encapsulación y ocultar la implementación.

Puede cambiar de opinión sobre cómo count elementos o cómo mantener que count. Si es una propiedad, está atascado: si se accede a ella a través de un método, puede cambiar la implementación subyacente sin afectar a los usuarios de la colección.

En Elixir hay realmente un esquema de nomenclatura claro asociado a él a través de los tipos en el lenguaje.

Al "contar" el número de elementos en una estructura de datos, Elixir también cumple una regla simple: la función se llama size si el la operación es en tiempo constante (es decir, el valor se pre-calcula) o length si la operación es lineal (es decir, calcular la longitud obtiene más lento a medida que la entrada crece).

Para mí, esto es un poco como preguntar si "foreach" es mejor que "para cada uno". Solo depende del lenguaje / marco.

Yo diría que depende del lenguaje particularque esté usando y clases. Por ejemplo en c# si estás usando Array tienes Property Length, si tienes algo que hereda deerableumerable tienes extension Method Count(), pero no es rápido. Y si has heredado de ICollection tienes Property Count.