count vs length vs size em uma coleção


167

Ao usar várias linguagens de programação e bibliotecas, notei vários termos usados ​​para o número total de elementos em uma coleção.

O mais comum parece ser length, counte size.

por exemplo.

array.length
vector.size()
collection.count

Existe algum termo preferido para ser usado? Depende de que tipo de coleção é? ie mutável / imutável

Existe uma preferência por ser uma propriedade em vez de um método?


E há List.Capacitypropriedade também em C #.
RBT

Espero que os novos idiomas evitem termos ambíguos.
Nikolay Klimchuk 26/10/19

Respostas:


231

Length() tende a se referir a elementos contíguos - uma string tem um comprimento, por exemplo.

Count() tende a se referir ao número de elementos em uma coleção mais flexível.

Size() tende a se referir ao tamanho da coleção, geralmente isso pode ser diferente do tamanho em casos como vetores (ou cadeias), pode haver 10 caracteres em uma cadeia, mas o armazenamento é reservado para 20. Também pode se referir ao número de elementos - verifique a fonte / documentação.

Capacity()- usado para se referir especificamente ao espaço alocado na coleção e não ao número de elementos válidos nela. Se o tipo tiver "capacidade" e "tamanho" definidos, "tamanho" geralmente se refere ao número de elementos reais.

Eu acho que o ponto principal é a linguagem e expressões humanas, o tamanho de uma string não parece muito óbvio, enquanto o comprimento de um conjunto é igualmente confuso, mesmo que eles possam ser usados ​​para se referir à mesma coisa (número de elementos ) em uma coleção de dados.


5
Então, o que é uma "coleção mais flexível"? Não estou vendo a diferença entre tamanho e contagem aqui.
Sophie Alpert

32
@ ben: size = slots disponíveis, count = elementos reais. size == conta quando a coleção está cheia.
Steven Evers

8
Voto negativo porque size()se refere ao número de elementos no vetor, não no seu capacity()… pelo menos em C ++, que eu acho que é o originador de vectors com sizes.
Dave Abrahams

10
@DaveAbrahams - eu nunca disse que era esse o caso. Leia isso novamente. Eu disse que "tende a se referir", nunca tentei fazer uma declaração específica que se aplicava igualmente a todas as permutações de todas as classes de coleção em todos os idiomas.
Gbjbaanb

2
@SnOrfus Acho que você entrou no reino da "capacidade" lá. std::vector(C ++), por exemplo, usa "capacidade" e "tamanho", onde você usa "tamanho" e "contagem", respectivamente. Na verdade, tudo em std::usos "tamanho" para a contagem elemento atual, mesmo std::string(que fornece "tamanho" para a compatibilidade do modelo e um "comprimento" completamente idênticos para ... conveniência humana eu acho).
Jason C

28

FWIW (e isso é quase inexistente), eu prefiro 'Count' porque parece indicar que ele retornará o número de elementos / itens da coleção de maneira bastante inequívoca.

Quando confrontado com os termos 'Comprimento' ou 'Tamanho', fico sempre pensando por um momento (ou mesmo sendo forçado a reler a documentação) se a maldita coisa vai me dizer quantos elementos existem na coleção ou como muitos bytes que a coleção está consumindo. Isso é particularmente verdadeiro para coleções que se destinam a serem contingentes, como matrizes ou seqüências de caracteres.

Mas ninguém que foi responsável pelas convenções de nomenclatura usadas pelas estruturas / bibliotecas padrão Java, BCL / .Net ou C / C ++ se incomodou em me perguntar, então você está preso ao que quer que tenha inventado.

Se eu fosse muito mais esperto do que sou e se chamasse Bjarne, todos vocês serão poupados da miséria ...

É claro que, de volta ao mundo real, você deve tentar se ater a qualquer convenção de nomenclatura usada pelo idioma / plataforma que você está usando (por exemplo, size()em C ++). Não que isso pareça ajudá-lo com seu Array.Lengthdilema.


16
Enquanto Comprimento e Tamanho são substantivos, Contagem também é um verbo, portanto, pode ser interpretado como contagem em tempo de execução (O (n)) versus pesquisa de um valor (O (1)).
MBX

Na verdade, isso é exatamente como ele é usado em LINQ: Enumerable.Count
Edward Brey

11

Os termos são um tanto intercambiáveis, embora em algumas situações eu prefira um ao outro. Normalmente, você pode obter o melhor uso se pensar em como descreveria o comprimento / tamanho / contagem desse elemento verbalmente para outra pessoa?

length()implica que o elemento tenha um comprimento. Uma string tem um comprimento. Você diz "uma string tem 20 caracteres", certo? Então tem um comprimento.

size()implica que o elemento tem um tamanho. Por exemplo, um arquivo tem um tamanho. Você diz "este arquivo tem um tamanho de 2 MB", certo? Então tem um tamanho.

Dito isto, uma string também pode ter um tamanho, mas eu esperaria algo mais aqui. Por exemplo, uma string UTF-16 pode ter um comprimento de 100 caracteres, mas como cada caractere é composto de dois bytes, eu esperaria que o tamanho fosse 200.

count()é muito incomum. O Objective-C usa count para o número de elementos em uma matriz. Alguém poderia argumentar se uma matriz tem um comprimento (como em Java), tem um tamanho (como na maioria das outras linguagens) ou tem uma contagem. No entanto, tamanho pode ser novamente o tamanho em bytes (se os itens da matriz tiverem 32 bits int, cada item tem 4 bytes) e o comprimento ... Eu não diria que "uma matriz possui 20 elementos", isso soa estranho para mim. Eu diria "uma matriz tem 20 elementos". Não tenho certeza se count expressa isso muito bem, mas acho que count é aqui uma forma abreviada de elementCount()e isso novamente faz muito mais sentido para uma matriz do que length () ou size ().

Se você criar objetos / elementos próprios em uma linguagem de programação, é melhor usar quaisquer outros elementos semelhantes, pois os programadores são usados ​​para acessar a propriedade desejada usando esse termo.


Seguindo sua analogia de cadeia, um arquivo deve ter um length, mas diferentes armazenamentos podem usar diferentes sizespara armazenar seus dados. Java também pensa assim em java.io.File # length () , mas parece que o resto do mundo discorda.
Ivan Balashov

1
@IvanBalashov Eu nunca usei "tamanho do arquivo" nas conversas diárias, para mim um arquivo não tem tamanho, mas um tamanho, e foi também o que escrevi na minha resposta. Sempre que estamos falando de bytes brutos, estamos falando do tamanho IMHO e um arquivo sem conteúdo específico mais próximo é apenas um monte de bytes. O comprimento geralmente não é usado para expressar a contagem de bytes, mas para expressar um acúmulo de elementos encadeados (bytes não são elementos para mim, mais os blocos de construção para formar elementos e eles também não são "encadeados").
Mecki

4

Contagem, eu acho que é o termo mais óbvio para usar se você estiver procurando o número de itens em uma coleção. Isso deve ser óbvio para novos programadores que ainda não se tornaram particularmente apegados a um determinado idioma.

E deve ser uma propriedade, pois é isso que é: uma descrição (também conhecida como propriedade) da coleção. Um método implicaria que ele precisava fazer algo na coleção para obter o número de itens e isso parece pouco intuitivo.


3

Hmm ... eu não usaria tamanho. Porque isso pode ser confundido com tamanho em bytes. Comprimento - pode fazer algum sentido para matrizes, desde que elas devam usar bytes de memória consequentes. Embora ... comprimento ... em quê? A contagem é clara. Quantos elementos. Eu usaria count.

Sobre propriedade / método, eu usaria a propriedade para marcar como rápida e o método para marcar como lenta.

E, o mais importante - eu me ateria aos padrões das linguagens / bibliotecas que você está usando.


Então, o que dizer de um DataBlock, apenas um monte de bytes. Tem um comprimento ou tem um tamanho?
Mecki

2

Adicionando à resposta de @ gbjbaanb ...

Se "propriedade" implica acesso público ao valor, eu diria que "método" é preferido simplesmente para fornecer encapsulamento e ocultar a implementação.

Você pode mudar de idéia sobre como fazer countelementos ou como mantém isso count. Se for uma propriedade, você está preso - se for acessado por meio de um método, poderá alterar a implementação subjacente sem afetar os usuários da coleção.


Por que você está "preso" se exposto como uma propriedade? As propriedades têm uma implementação subjacente que pode mudar com a mesma facilidade sem interromper a interface. De fato, a maioria das linguagens implementa propriedades como métodos get / set gerados pelo compilador de qualquer maneira ... você simplesmente não pode chamá-las diretamente.
Scott Dorman

A que "maioria dos idiomas" você está se referindo? C, C ++, Java (apenas para citar alguns) não fazem isso. Ruby e Groovy eu sei. Observe como iniciei a resposta também: "Se 'propriedade' implica ..." Por que preso? Se a interface com as mudanças de classe, os clientes têm à mudança (em geral)
Ken Gentil

1

No Elixir, na verdade, existe um esquema de nomenclatura claro associado a ele entre os tipos no idioma.

Ao "contar" o número de elementos em uma estrutura de dados, o Elixir também cumpre uma regra simples: a função é nomeada sizese a operação estiver em tempo constante (ou seja, o valor é pré-calculado) ou lengthse a operação for linear (ou seja, calcular o comprimento fica mais lento à medida que a entrada aumenta).


0

Para mim, isso é um pouco como perguntar se "foreach" é melhor que "for each". Depende apenas da linguagem / estrutura.


E o que isso importa? O que muda? Todos nós vamos escrever e-mails irritados para o pessoal de Java por escolher dois e ser inconsistente?
S.Lott 18/11/2008

1
Esse é o meu ponto. Por que saber o que é melhor. É o que é.
EBGreen

0

Eu diria que depende do idioma específico que você está usando e das classes . Por exemplo, em c #, se você estiver usando Array, terá Comprimento da Propriedade ; se possuir algo que herda de IEnumerable, terá a extensão Method Count (), mas não é rápido. E se você herdou do ICollection, possui Contagem de propriedades .

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.