підрахувати довжину проти розміру в колекції

З використанням декількох мов програмування та бібліотек я помітив різні терміни, що використовуються для загальної кількості елементів колекції.

Найпоширенішими, здається length, є count, і size.

напр.

array.length
vector.size()
collection.count

Чи є якийсь кращий термін, який слід використовувати? Чи залежить це від типу колекції? тобто. змінний / незмінний

Чи є перевага, щоб воно було властивістю, а не методом?

Length() як правило, посилається на суміжні елементи - рядок, наприклад, має довжину.

Count() має тенденцію посилатися на кількість елементів у нещільній колекції.

Size() як правило, посилається на розмір колекції, часто це може відрізнятися від довжини у таких випадках, як вектори (або рядки), в рядку може бути 10 символів, але зберігання зарезервовано для 20. Це також може позначати число елементи - перевірити джерело / документацію.

Capacity()- використовується для конкретного посилання на виділений простір у колекції та не кількість дійсних елементів у ньому. Якщо тип має і "ємність", і "розмір", тоді "розмір" зазвичай відноситься до кількості фактичних елементів.

Я думаю, що головна суть зводиться до людської мови та ідіом, розмір рядка не здається дуже очевидним, в той час як довжина набору однаково заплутана, хоча вони можуть використовуватися для позначення одного і того ж (кількість елементів) ) у збірці даних.

FWIW (і це марно близько до нічого), я віддаю перевагу "Count", тому що це, здається, вказує на те, що кількість елементів / елементів колекції повертається досить однозначно.

Коли я стикаюся з термінами "Довжина" або "Розмір", я часто на мить замислююсь (або навіть змушений перечитувати документацію), чи проклята річ підкаже мені, скільки елементів у колекції або як багато байтів збирає колекція. Особливо це стосується колекцій, які мають бути неперервними, як масиви чи рядки.

Але ніхто, хто несе відповідальність за умови іменування, використовувані стандартними рамками / бібліотеками Java, BCL / .Net або C / C ++, не намагався запитати мене, тож ви все зациклювались на тому, що вони придумали.

Якби я був набагато розумніший, ніж я, і був названий Б'ярне, усі ви могли б пощадити нещастя ...

Звичайно, повертаючись до реального світу, ви повинні намагатися дотримуватися будь-якої конвенції про іменування, якою використовується мова / платформа, яку ви використовуєте (наприклад, size()в C ++). Не те, що це, здається, допоможе вам у вашій Array.Lengthдилемі.

Умови дещо взаємозамінні, хоча в деяких ситуаціях я віддаю перевагу одне одному. Зазвичай ви можете отримати найкраще використання, якщо задумаєтесь про те, як би ви описували довжину / розмір / кількість цього елемента усно словесно для іншої людини?

length()випливає, що елемент має довжину. Рядок має довжину. Ви кажете "рядок довжиною 20 символів", правда? Так вона має довжину.

size()випливає, що елемент має розмір. Наприклад, файл має розмір. Ви кажете "розмір цього файлу - 2 Мб", правда? Так вона має розмір.

Однак це означає, що рядок також може мати розмір, але я очікую тут ще чогось. Наприклад, рядок UTF-16 може мати довжину 100 символів, але оскільки кожен символ складається з двох байтів, я очікую, що його розмір буде 200.

count()дуже незвично. Objective-C використовує count для кількості елементів у масиві. Можна заперечити, якщо масив має довжину (як у Java), має розмір (як у більшості інших мов) або має кількість. Однак розмір знову може бути розміром у байтах (якщо елементи масиву 32-бітові int, кожен елемент - 4 байти) та довжиною ... Я б не сказав "масив має 20 елементів", це звучить досить дивно я. Я б сказав, що "масив має 20 елементів". Я не впевнений, що підрахунок виражає це дуже добре, але я думаю, що підрахунок тут є короткою формою, elementCount()і це знову має набагато більше сенсу для масиву, ніж length () або size ().

Якщо ви створюєте власні об'єкти / елементи мовою програмування, найкраще використовувати будь-які інші подібні елементи, оскільки програмісти використовують для доступу до потрібного властивості за допомогою цього терміна.

Підрахунок, я думаю, це найбільш очевидний термін, який потрібно використовувати, якщо ви шукаєте кількість предметів у колекції. Це навіть очевидно для нових програмістів, які ще не особливо прив’язані до даної мови.

І це має бути властивість, як це є: опис (він же властивість) колекції. Метод передбачає, що він повинен щось зробити для колекції, щоб отримати кількість предметів, і це просто здається неінтуїтивним.

Хм ... я б не використовував розмір. Тому що це може бути змішено з розміром у байтах. Довжина - може мати певний сенс для масивів, якщо вони повинні використовувати послідовні байти пам'яті. Хоча ... довжина ... в чому? Граф зрозумілий. Скільки елементів. Я б використовував кол.

Щодо властивості / методу, я би використовував властивість, щоб позначити, що це швидко, а метод, щоб позначити його повільно.

І, найголовніше - я б дотримувався стандартів мов / бібліотек, якими ви користуєтесь.

Додавання до відповіді @ gbjbaanb ...

Якщо "властивість" передбачає доступ громадськості до значення, я б сказав, що "метод" бажано просто забезпечити інкапсуляцію і приховати реалізацію.

Ви можете змінити свою думку щодо того, як скласти countелементи або як ви їх підтримуєте count. Якщо це властивість, ви застрягли - якщо до нього звернутися за допомогою методу, ви можете змінити базову реалізацію, не впливаючи на користувачів колекції.

У Elixir насправді існує чітка схема іменування, пов’язана з нею за різними типами мови.

Під час "підрахунку" кількості елементів у структурі даних Elixir також дотримується простого правила: функція називається, sizeякщо операція знаходиться в постійному часі (тобто значення заздалегідь обчислюється) або lengthякщо операція лінійна (тобто обчислення довжина стає повільнішою у міру зростання вводу).

Для мене це трохи схоже на запитання, чи краще "передбачити", ніж "для кожного". Це просто залежить від мови / рамки.

Я б сказав, що це залежить від конкретної мови, якою ви користуєтесь, та занять . Наприклад, у c #, якщо ви використовуєте масив, у вас є довжина властивості , якщо у вас є щось, що успадковується від IEnumerable, у вас є розширення Method Count (), але це не швидко. І якщо ви успадкували від ICollection, у вас є кількість майна .