Количество vs длина vs размер в коллекции
Используя несколько языков программирования и библиотек, я заметил, что для определения общего количества элементов в коллекции используются различные термины.
Наиболее распространенными являются length, count и size.
например.
array.length
vector.size()
collection.count
Можно ли использовать какой-нибудь предпочтительный термин? Зависит ли это от того, какой это сбор? т.е. изменчивый / неизменный
Есть ли предпочтение, чтобы это было свойством, а не методом?
Я надеюсь, что новые языки позволят избежать двусмысленных терминов.
Ответы 9
Для меня это немного похоже на вопрос, лучше ли foreach или for each. Это просто зависит от языка / фреймворка.
И какое это имеет значение? Что меняется? Собираемся ли мы все писать гневные письма людям, использующим Java, за то, что они выбрали два и были непоследовательными?
Это моя точка зрения. Зачем гадать, что лучше. Что есть, то есть.
Хм ... Я бы не стал использовать размер. Потому что это можно спутать с размером в байтах. Длина - может иметь смысл для массивов, если предполагается, что они используют последовательные байты памяти. Хотя ... длина ... в чем? Подсчет ясен. Сколько элементов. Я бы использовал счет.
Что касается свойства / метода, я бы использовал свойство, чтобы отметить его быстро, и метод, чтобы отметить его медленный.
И, самое главное, я бы придерживался стандартов языков / библиотек, которые вы используете.
Так что насчет DataBlock, всего лишь кучи байтов. У него есть длина или размер?
Считаю, что это наиболее очевидный термин, который можно использовать, если вы ищете количество элементов в коллекции. Это должно быть очевидно даже для начинающих программистов, которые еще не особенно привязаны к данному языку.
И это должно быть свойство таким, какое оно есть: описание (также известное как свойство) коллекции. Метод подразумевает, что он должен что-то сделать с коллекцией, чтобы получить количество элементов, и это кажется неинтуитивным.
Length() имеет тенденцию относиться к смежным элементам - например, строка имеет длину.
Count() имеет тенденцию относиться к количеству элементов в более свободной коллекции.
Size() имеет тенденцию относиться к размеру коллекции, часто он может отличаться от длины в таких случаях, как векторы (или строки), в строке может быть 10 символов, но память зарезервирована для 20. Это также может относиться к числу элементов - проверьте источник / документацию.
Capacity() - используется для обозначения выделенного пространства в коллекции, а не количества допустимых элементов в ней. Если для типа определены как «емкость», так и «размер», то «размер» обычно относится к количеству фактических элементов.
Я думаю, что основная суть сводится к человеческому языку и идиомам, размер строки не кажется очень очевидным, в то время как длина набора в равной степени сбивает с толку, даже если они могут использоваться для обозначения одного и того же (количество элементов ) в коллекции данных.
Так что же такое «более свободная коллекция»? Я не вижу здесь разницы между размером и количеством.
@ben: size = доступные слоты, count = фактические элементы. size == count, когда коллекция заполнена.
@SnOrfus, это все еще верно, но я имел в виду коллекции, в которых не было никаких значимых смежных элементов, например, карты или словаря. Вы бы не сказали, что набор имеет длину 10 элементов, в нем будет счетчик из 10 элементов.
Голосование против, потому что size() относится к количеству элементов в векторе, нет - к capacity()… по крайней мере, в C++, который, как мне кажется, является источником vector с size.
@DaveAbrahams - Я никогда не говорил, что это так. Прочтите еще раз. Я сказал, что это «имеет тенденцию ссылаться», я даже никогда не пытался сделать конкретное утверждение, которое одинаково применялось бы ко всем перестановкам всех классов коллекций на всех языках.
Совершенно несвязанный, но что интересно, «длина» (или мера) математического набора определенно не совпадает с его «размером» (или количеством элементов в наборе). Пример: интервал [0,1] имеет «длину» 1, но имеет «размер» aleph_1.
@SnOrfus Я думаю, вы вошли в сферу "возможностей". std::vector (C++), например, использует «емкость» и «размер», где вы используете «размер» и «количество» соответственно. На самом деле, все в std:: использует «размер» для текущего количества элементов, даже std::string (который обеспечивает «размер» для совместимости с шаблоном и полностью идентичную «длину» для ... человеческого удобства, я полагаю).
Итак, чтобы быть больше какао, я должен сделать .numberOfElements()? ;П
Добавление к ответу @ gbjbaanb ...
Если «свойство» подразумевает открытый доступ к значению, я бы сказал, что «метод» предпочтительнее просто для обеспечения инкапсуляции и сокрытия реализации.
Вы можете изменить свое мнение о том, как работать с элементами count или как вы поддерживаете этот count. Если это свойство, вы застряли - если к нему обращаются через метод, вы можете изменить базовую реализацию, не затрагивая пользователей коллекции.
Почему вы «застряли», если это выставлено как собственность? Свойства имеют базовую реализацию, которая может быть изменена так же легко, не нарушая интерфейса. Фактически, большинство языков в любом случае реализуют свойства как методы get / set, созданные компилятором ... вы просто не можете вызывать их напрямую.
Какие «большинство языков» вы имеете в виду? C, C++, Java (и это лишь некоторые из них) этого не делают. Я знаю, что Ruby и Groovy верны. Обратите внимание, как я начал отвечать: «Если« свойство »подразумевает ...» Почему застрял? Если интерфейс к классу меняется, клиенты должны измениться (вообще говоря)
Эти термины в некоторой степени взаимозаменяемы, хотя в некоторых ситуациях я предпочитаю одно другому. Обычно лучше всего использовать Как бы вы устно описали длину / размер / количество этого элемента другому человеку?.
length() подразумевает, что элемент имеет длину. У строки есть длина. Вы говорите, что «строка состоит из 20 символов», верно? Итак, у него есть длина.
size() подразумевает, что элемент имеет размер. Например. файл имеет размер. Вы говорите, что «этот файл имеет размер 2 МБ», верно? Итак, у него есть размер.
Тем не менее, строка также может иметь размер, но я бы ожидал здесь чего-то другого. Например. строка UTF-16 может иметь длину 100 символов, но поскольку каждый символ состоит из двух байтов, я ожидаю, что размер будет 200.
count() очень необычный. Objective-C использует счетчик для количества элементов в массиве. Кто-то может возразить, имеет ли массив длину (как в Java), размер (как в большинстве других языков) или счетчик. Однако размер может снова быть размером в байтах (если элементы массива - 32-битные int, каждый элемент - 4 байта) и длиной ... Я бы не сказал, что «массив имеет длину 20 элементов», что звучит довольно странно для меня. Я бы сказал, что «массив состоит из 20 элементов». Я не уверен, что count это очень хорошо выражает, но я думаю, что count - это краткая форма для elementCount(), и это снова имеет гораздо больше смысла для массива, чем length () или size ().
Если вы создаете собственные объекты / элементы на языке программирования, лучше всего использовать любые другие аналогичные элементы, поскольку программисты привыкли получать доступ к желаемому свойству, используя этот термин.
Следуя аналогии со строкой, файл должен иметь length, но разные хранилища могут использовать разные sizes для хранения своих данных. Java тоже так думает в java.io.File # length (), но похоже, что остальной мир не согласен.
@IvanBalashov Я никогда не использовал термин «длина файла» в повседневных разговорах, для меня файл имеет не длину, а размер, и это то же самое, что я написал в своем ответе. Всякий раз, когда мы говорим о необработанных байтах, мы говорим о размере IMHO, а файл без более конкретного содержимого - это просто набор байтов. Длина обычно не используется для выражения количества байтов, а для выражения накопления элементов, связанных друг с другом (байты для меня не элементы, а скорее строительные блоки для формирования элементов, и они также не «связаны друг с другом»).
FWIW (и это исчезающе близко к нулю), я предпочитаю «Счетчик», потому что он, кажется, указывает на то, что он будет довольно однозначно возвращать количество элементов / элементов в коллекции.
Столкнувшись с терминами «длина» или «размер», я часто на мгновение задаюсь вопросом (или даже вынужден перечитывать документацию), скажет ли мне эта чертова штука, сколько элементов в коллекции или как много байтов занимает коллекция. Это особенно верно для коллекций, которые должны быть непрерывными, как массивы или строки.
Но никто, кто отвечал за соглашения об именах, используемые стандартными фреймворками / библиотеками Java, BCL / .Net или C / C++, не удосужился спросить меня, так что вы все застряли в том, что они придумали.
Если бы я был намного умнее, чем я, и меня звали бы Бьярн, вы бы избавились от страданий ...
Конечно, вернувшись в реальный мир, вы должны попытаться придерживаться любого соглашения об именах, которое используется языком / платформой, которую вы используете (например, size() в C++). Не то чтобы это помогло вам с дилеммой Array.Length.
Хотя длина и размер являются существительными, счетчик также является глаголом, поэтому его можно интерпретировать как подсчет во время выполнения (O (n)) по сравнению с поиском значения (O (1)).
Действительно, именно так он используется в LINQ: Enumerable.Count
Я бы сказал, что это зависит от конкретного язык, который вы используете, и классы. Например, в C#, если вы используете Array, у вас есть длина Имущество, если у вас есть что-то, что наследуется от IEnumerable, у вас есть расширение Методика Count (), но это не быстро. И если вы унаследовали от ICollection, у вас есть Имущество Count.
В Elixir на самом деле существует четкая схема именования, связанная с типами на языке.
When “counting” the number of elements in a data structure, Elixir also abides by a simple rule: the function is named
sizeif the operation is in constant time (i.e. the value is pre-calculated) orlengthif the operation is linear (i.e. calculating the length gets slower as the input grows).
И в C# есть свойство
List.Capacity.