Як назвати змінну, коли слово є і іменником, і дієсловом


48

Я зіткнувся з вирішенням проблеми із загальними критеріями:

  • іменники для змінних
  • дієслова за функціями

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

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

Один із прикладів - з a battery. А batteryмає chargeі ви також charge()можете акумулятор.

Я думаю, що мати те і інше, Battery.Chargeі Battery.Charge(value)буде бентежити майбутніх розробників.

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

Моє запитання, чи існує інший / кращий спосіб вирішення цього конфлікту в конвенції про іменування?


Деякі додаткові читання з цього приводу. Ніхто насправді не стосувався конкретного мого питання.


3
зробіть функцію зарядки addCharge легкою і чіткою
храповий

2
Чи можете ви приєднати змінну іменника до "Current-"? Отже, "CurrentCharge" проти "Charge ()"?
Брайан Сніг

6
або просто ChargeLevel, щоб отримати поточний заряд
грохот урод

5
Складіть слово. WordNet не думає enqueue, що це слово, але його дієслово на Java. Як щодо doCharge? Це тест на симетрію все ще не вдасться, оскільки інші ваші методи не матимуть цього приставки
Мізерна змінна

5
"Поточний" = зараз, або "струм" = потік заряду. Єдине справжнє рішення - замінити англійську мову більш розумною мовою!
DarenW

Відповіді:


38

У подібних ситуаціях я намагаюся знайти синоніми. У цьому випадку я б використав "поповнення" для дієслова. Значення "повторно" дещо зайве, але сенс зрозумілий. Використання простого "заряду" для залишку заряду в акумуляторі неоднозначне, оскільки в ньому не вказані фізичні одиниці. Я вважаю за краще "availableAmpHours", "hoursUntilRecharge" або щось подібне. Елементи залежать від того, що зручно для програми.

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


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

1
Я віддаю перевагу дієсловам для дорогих функцій, що не мутують. Наприклад, функції, які виконують запит у базі даних.
Брайан

20

Просто викидаючи це туди, але, можливо, рішенням цього приводу іменування неоднозначності є вилучення цієї функціональності з акумулятора повністю. Я ніколи не бачив самозарядної батареї, і для мене було б більше сенсу мати клас BatteryCharger. Це допоможе зберегти ваші занепокоєння більш відокремленими та зробити дії більш чіткими.

battery.Charge(50) проти batteryCharger.Charge(battery, 50)

Для мене друга форма набагато зрозуміліша і зберігає весь ваш код «зарядки» в одному місці, а не розповсюджує його на всі ваші класи акумуляторів.


6
Це не погана думка, але в цьому випадку Batteryце абстракція від акумулятора + система зарядки. У нашому додатку не потрібно розбивати два аспекти на окремі об’єкти, тому вони Batteryзручні в один (ака ) для зручності. Зрештою, фізика зарядженої батареї диктує, що вона має якусь функцію приймати заряд.

У такому випадку я заявляю, що відповідь Кевіна Клайна - це те, що ви шукаєте. Для наочності я б використав «Перезарядка» та «Розрядка» для функцій, що мутують, і зарядку для імені властивості. Можливо, ChargePercent також був би хорошим.
mortalapeman

Ви, можливо, програміст Java? Це явно порушення Не повторюйте себе. Насправді ви повторюєте ВСЕ, крім параметра "50". Я не міг би придумати гірший приклад порушення DRY, якщо б спробував.
бокс

@boxed Ти береш про мій приклад? Тому що я не впевнений, як ви можете стверджувати, що я порушую DRY, коли у мене немає реалізації. Я величезний прихильник принципів SOLID і просто не бачу, як ви прийшли до цього висновку.
mortalapeman

Ви порушуєте DRY, створюючи непотрібний клас BatteryCharger, який певним чином призведе до зміни стану батареї. Тож BatteryCharger прийме деякий внесок, який потім негайно передасть Battery.
Кевін Клайн

9

Уникайте подвійних значень

Ви навмисно вибрали слово, яке має більше одного значення, і це перше рішення - проблема. Є багато слів, які є проблематичними для програмістів. Іншим прикладом може бути phone. Ви можете phoneкогось, або у вас phoneв кишені.

Використовуйте геттери та сетери

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

Battery.Charge            // would be a property
Battery.setCharge(value)  // would set the property
Battery.getCharge()       // would get the property

Властивості - це держави, а не іменники

Думаю, ви помиляєтесь, класифікуючи властивості об'єкта як іменники, а змінні також можна вважати станами. Вони є державами, що відповідають місцевим масштабам їх існування.

Ви можете описати значення, яке вони мають як іменник, але я не впевнений, що це правда у всіх випадках.

В термінології OOP властивості об'єкта описують стан цього об'єкта. У вашому випадку Batteryце об'єкт, і це Chargeстан. Так це буде властивістю об'єкта, але це залежить від контексту того, як він використовується.

Якщо вам потрібно вміти Chargeакумулятор, а також знати, що це за струм Charge, то у вас є проблема.

Використання області застосування для забезпечення контексту

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

Batter._charge            // a hidden private property
Battery.setCharge(value)  // would set the private property
Battery.getCharge()       // would get the private property
Battery.Charge()          // would perform the Charge action

Методи - дієслова

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

Слово Charge- це дієслово, але це також іменник. При використанні для виклику способу дії стає зрозумілим, що дієслово вживається Battery.Charge(....).

Але контекст дуже важливий. Хоча слово Charge()є дієсловом, воно не настільки значуще, як startCharging().

Правильні методи Batteryможуть включати в себе Charging, Discharging, setCharge, getCharge, hasCharge, Dischargeі Charged.

Прості методи з одним словом часто не чітко заявляють про свої дії чітко, але є такі випадки, як openі closeде потрібно пояснення мало.

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


2
Для запису клієнт - це той, хто використовує неоднозначну термінологію. Я не створював цього безладу. :-) Я поставив це питання, оскільки думав, що, можливо, я не єдиний, хто впадає в таку ситуацію. У вашій відповіді є деякі дійсні моменти. В даному конкретному випадку, ми не працюємо в зернистості часу, StartCharge()і EndCharge()буде означати. Насправді ця термінологія додала б значних витрат на обробку акумуляторної системи. На кожному інтервалі він може Charge()або Discharge().

1
Основна боротьба полягає у збереженні внутрішньої семантики програмування синхронною з термінологією, якою користується клієнт. Charge, як видається, є найбільш зрозумілим для цього домену неоднозначним словом. Є кілька інших.

6

Додайте їх дієсловам, які зроблять їх дієсловом чи іменником.

Battery.doCharge()

Battery.getCharge()

4

Що стосується дієслова, я думаю, що Chargeце нормально. Для відмінка іменника це getCurrentChargeLevelпрацювало б для вас?


Не впевнений у цьому. Оскільки ми використовуємо C #, ми можемо оголосити отримання та встановити у Властивості замість того, щоб потребувати окремих функцій. Незалежно від цього я переймаюся технічним обслуговуванням і як це буде виглядати, коли я забув те, що написав. Чи getCurrentChargeLevel()все-таки не потрібно було б посилатися на внутрішню змінну Battery, і як би називалася ця змінна?

це заряд напруги чи відсотків?
mhoran_psprep

1
@ GlenH7: Ах, бачу. Ви не вказали C # і мій мозок знаходиться в режимі Java. Ну так чи інакше, я думаю, що для іменника, що представляє кількість заряду, що знаходиться в даний час в акумуляторі, щось Battery.currentChargeLevelможе працювати. Ви можете спробувати використовувати Battery.coloumbsабо , Battery.ampereHoursале це може бути не так очевидно ...
FrustratedWithFormsDesigner

1
@mhoran_psprep - ні. ;-) Charge- це те, Energyщо Power(Вольт * Амп == Вт) множиться на час. Так що в цьому випадку заряд - це число. Існує також державний збір, який, як правило, становить відсоток.

@FrustratedWithFormsDesigner - так, я покинув C #, оскільки вважав, що справа в ширшому куті застосовна незалежно від мови. Watt*timeнапевно не відповідав би дизайнерським розмовам, але ChargeLevelбуде.

0

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

Дельта (у випадках, коли є зміна, але неоднозначна) - це модифікатор, який я використовую та рекомендую іншим весь час для передачі змін стану (навіть якщо дієслово напів очевидне).


0

Угорська нотація на допомогу. Ви можете мати intChargeі fcnCharge(value), таким чином, уникати плутанини і не додавати божевільного довгого імені, коли три букви працюватимуть чудово.

Або ви можете просто використовувати те саме ім’я та дозволити IDE впоратися з цим. Створення більш тривалого або іншого імені може бути настільки ж заплутаним у довгостроковій перспективі.


+1 для унікальної точки зору на відповідь. На жаль, угорські позначення прямо вказані у відповідності до наших вказівок щодо стилю коду. Це не змінює потенційного достоїнства вашої відповіді, лише те, що я не можу використовувати це як своє фактичне рішення.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.