2008-11-18 11 views
136

Utilizando varios lenguajes de programación y bibliotecas, he notado varios términos utilizados para la cantidad total de elementos en una colección.recuento frente a la longitud frente al tamaño en una colección

Los más comunes parecen ser length, count y size.

por ejemplo.

array.length 
vector.size() 
collection.count 

¿Hay algún término preferido para usar? ¿Depende del tipo de colección que sea? es decir. mutable/inmutable

¿Existe una preferencia por ser una propiedad en lugar de un método?

+0

Y también está la propiedad 'List.Capacity' en C#. – RBT

+0

Espero que los nuevos idiomas eviten términos ambiguos. –

Respuesta

196

Length() tiende a referirse a elementos contiguos: una cadena tiene una longitud, por ejemplo.

Count() tiende a hacer referencia a la cantidad de elementos en una colección más suelta.

Size() tiende a referirse al tamaño de la colección, a menudo esto puede ser diferente de la longitud en casos como vectores (o cadenas), puede haber 10 caracteres en una cadena, pero el almacenamiento está reservado para 20. También puede referirse a la cantidad de elementos - verificar fuente/documentación.

Capacity() - Se utiliza para referirse específicamente al espacio asignado en la colección y no al número de elementos válidos en él. Si el tipo tiene definidos tanto "capacidad" como "tamaño", entonces "tamaño" generalmente se refiere a la cantidad de elementos reales.

Creo que el punto principal es el lenguaje humano y las expresiones idiomáticas, el tamaño de una cuerda no parece muy obvio, mientras que la longitud de un conjunto es igualmente confusa aunque podrían usarse para referirse a lo mismo (número de elementos) en una colección de datos.

+4

Entonces, ¿qué es una "colección más suelta"? No veo la diferencia entre el tamaño y el recuento aquí. –

+26

@ben: tamaño = espacios disponibles, recuento = elementos reales. tamaño == cuenta cuando la colección está llena. –

+0

@SnOrfus, eso sigue siendo cierto, pero me refería a colecciones que no tenían ningún elemento contiguo significativo, por ejemplo, un mapa o un diccionario. No diría que un conjunto tiene una longitud de 10 elementos, habría un recuento de 10 elementos en eso. – gbjbaanb

0

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

+0

Y, ¿qué importa? ¿Que cambios? ¿Vamos a escribir correos electrónicos enojados a la gente de Java por elegir dos y ser inconsistentes? –

+1

Ese es mi punto. ¿Por qué preguntarse qué es mejor? Es lo que es. – EBGreen

3

Hmm ... No usaría el tamaño. Porque esto puede confundirse con el tamaño en bytes. Longitud: podría tener algún sentido para las matrices, siempre que se suponga que utilicen los bytes de memoria correspondientes. Aunque ... longitud ... ¿en qué? La cuenta es clara. Cuantos elementos. Yo usaría el conteo.

Sobre la propiedad/método, yo usaría la propiedad para marcar que es rápido, y el método para marcar que es lento.

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

+0

¿Qué pasa con un DataBlock, solo un grupo de bytes? ¿Tiene una longitud o tiene un tamaño? – Mecki

3

Recuento Creo que es el término más obvio para usar si está buscando la cantidad de elementos de una colección. Eso debería ser incluso obvio para los nuevos programadores que aún no se han apegado particularmente a un idioma determinado.

Y debe ser una propiedad, ya que 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 en la colección para obtener el número de elementos y eso parece poco intuitivo.

2

Agregando a la respuesta de @ gbjbaanb ...

Si "propiedad" implica acceso público al valor, diría que se prefiere "método" simplemente para proporcionar encapsulación y ocultar la implementación.

Es posible que cambie de opinión sobre cómo count elementos o cómo se mantiene ese count. Si se trata de una propiedad, está atascado: si se procesa a través de un método, puede cambiar la implementación subyacente sin afectar a los usuarios de la colección.

+0

¿Por qué estás "atascado" si está expuesto como una propiedad? Las propiedades tienen una implementación subyacente que puede cambiar con la misma facilidad sin romper la interfaz. De hecho, la mayoría de los lenguajes implementan propiedades como métodos get/set generados por el compilador de todos modos ... simplemente no puedes llamarlos directamente. –

+0

¿A qué "mayoría de idiomas" se está refiriendo? C, C++, Java (solo por nombrar algunos) no hacen esto. Ruby y Groovy sé que sí. Tenga en cuenta cómo comencé la respuesta, también: "Si 'propiedad' implica ..." ¿Por qué atascado?Si la interfaz de la clase cambia, los clientes tienen que cambiar (en términos generales) –

8

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

length() implica que el elemento tiene una longitud. Una cuerda tiene una longitud. Usted dice "una cadena tiene 20 caracteres", ¿verdad? Entonces tiene una longitud.

size() implica que el elemento tiene un tamaño. P.ej. un archivo tiene un tamaño. Usted dice "este archivo tiene un tamaño de 2 MB", ¿verdad? Entonces tiene un tamaño.

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

count() es muy inusual. Objective-C usa recuento para la cantidad de elementos en una matriz. 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 idiomas) o tiene un recuento. Sin embargo, el tamaño podría volver a ser el tamaño en byte (si los elementos de la matriz son 32 bits int, cada elemento es 4 bytes) y longitud ... No diría que "una matriz tiene 20 elementos", eso suena bastante extraño yo. Diría que "una matriz tiene 20 elementos". No estoy seguro si el conteo lo expresa muy bien, pero creo que el recuento es aquí una forma abreviada para elementCount() y eso tiene mucho más sentido para una matriz que la longitud() o el tamaño().

Si crea objetos/elementos propios en un lenguaje de programación, es mejor usar cualquier otro elemento similar que use, ya que los programadores están acostumbrados a acceder a la propiedad deseada utilizando ese término.

+0

Siguiendo la analogía de la cadena, un archivo debe tener una "longitud", pero diferentes almacenamientos pueden usar diferentes "tamaños" para almacenar sus datos. Java también lo cree en _java.io.File # length() _, pero parece que el resto del mundo no está de acuerdo. –

+0

@IvanBalashov Nunca utilicé "longitud de archivo" en la conversación diaria, para mí un archivo no tiene longitud sino un tamaño y eso también es lo que escribí en mi respuesta. Cada vez que hablamos de bytes sin procesar estamos hablando de tamaño en mi humilde opinión y un archivo sin contenido específico más cercano es solo un montón de bytes. Por lo general, la longitud no se utiliza para expresar el recuento de bytes, sino para expresar una acumulación de elementos unidos (los bytes no son elementos para mí, más los elementos básicos para formar elementos y tampoco están "enlazados"). – Mecki

26

FWIW (y eso se acerca a nada), prefiero 'Contar' porque parece indicar que devolverá la cantidad de elementos/elementos de la colección de forma bastante inigualable.

Cuando me enfrento a los términos 'Longitud' o 'Tamaño', a menudo me pregunto por un momento (o incluso me obligan 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 las colecciones que están destinadas a contingous como matrices o cadenas.

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

Si sólo eran mucho más inteligente que yo y fue nombrado Bjarne, todos ustedes se hubiera salvado de la miseria ...

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

+14

Mientras Longitud y Tamaño son sustantivos, Count también es un verbo, por lo que podría interpretarse como contar en tiempo de ejecución (O (n)) vs buscar un valor (O (1)). – mbx

+0

De hecho, así es exactamente como se usa en LINQ: [Enumerable.Count] (https://docs.microsoft.com/en-us/dotnet/api/system.linq.enumerable.count) –

0

Yo diría que depende de un particular idioma que está usando y clases. Por ejemplo, en C# si está utilizando Array tiene Propiedad Longitud, si tiene algo que hereda de IEnumerable, tiene la extensión Método Count(), pero no es rápido. Y si has heredado de ICollection tienes Propiedad Count.

0

En Elixir, en realidad hay un esquema de nomenclatura claro asociado a él en todos los tipos del idioma.

Cuando “contar” el número de elementos en una estructura de datos, Elixir también se rige por una regla simple: la función se denomina size si la operación es en tiempo constante (es decir, el valor es pre-calculado) o length si la operación es lineal (es decir, el cálculo de la longitud se hace más lento a medida que aumenta la entrada ).

Cuestiones relacionadas