Как назвать переменную, когда слово является существительным и глаголом

48

Я столкнулся с проблемой в угловом случае под общим руководством:

  • существительные для переменных
  • глаголы для функций

В частности, у меня есть случай, когда слово неоднозначно - это может быть глагол или существительное. И в некоторых случаях, когда мы обсуждаем приложение, оно будет использоваться обоими способами в одном предложении.

Я намерен сделать так, чтобы программа оставалась читаемой как для будущих разработчиков, так и для меня, когда я вернусь к разделам кода несколько месяцев спустя.

Один из примеров с 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? Он по-прежнему не пройдет тест на симметрию, потому что ваши другие методы не будут иметь этот префикс
Miserable Variable
5
«Ток» = сейчас или «ток» = поток заряда. Единственное реальное решение - заменить английский на более разумный язык!
DarenW

Ответы:

38

В подобных ситуациях я пытаюсь найти синонимы. В этом случае я бы использовал «перезарядку» для глагола. «Ре» немного избыточен, но смысл ясен. Использование простого «заряда» для оставшегося заряда в аккумуляторе неоднозначно, потому что оно не указывает никаких физических единиц. Я бы предпочел «availableAmpHours», «hoursUntilRecharge» или что-то подобное. Единицы будут зависеть от того, что удобно для приложения.

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

Кевин Клайн
источник
2
Отличная точка на юнитах. В этом случае единицы измерения явно исключаются, поскольку они могут меняться в зависимости от того, какой анализ мы проводим. То есть мы используем разные временные шкалы, и Батарея корректирует свои действия в соответствии со шкалой анализа.
1
Я предпочитаю глаголы для дорогих, не мутирующих функций. Например, функции, которые запускают запрос к базе данных.
Брайан
20

Просто добавьте это, но, возможно, решением для этого случая двусмысленности имен является полное удаление этой функциональности из батареи. Я никогда не видел самозаряжающуюся батарею, и для меня было бы больше смысла иметь класс BatteryCharger. Это поможет сохранить ваши проблемы более разъединенными и сделает действие более явным.

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

Для меня вторая форма гораздо более понятна и хранит весь ваш код "Зарядка" в одном месте, а не разбрасывает его по всем классам батарей.

mortalapeman
источник
6
Это неплохая мысль, но в данном случае Batteryэто абстракция для системы аккумулятор + зарядка. Наше приложение не требует разделения двух аспектов на отдельные объекты, поэтому Batteryдля удобства они объединены в один (иначе ). В конечном счете, физика заряжаемой батареи диктует, что она имеет какую-то функцию для принятия заряда.
В этом случае, я утверждаю, что ответ Кевина Клайна - это то, что вы ищете. Для ясности, я бы использовал Recharge and Discharge для функций мутирования и Charge для имени свойства. Возможно, ChargePercent тоже подойдет.
смертный
Вы возможно программист на Java? Это явно нарушение «Не повторяйся». На самом деле, вы повторяете ВСЕ, кроме параметра «50». Я не мог придумать худший пример СУХОГО нарушения, если бы попытался.
штучной упаковке
@boxed Вы принимаете мой пример? Потому что я не уверен, как вы можете утверждать, что я нарушаю DRY, когда у меня нет реализации. Я большой сторонник твердых принципов и просто не вижу, как вы пришли к такому выводу.
смертный человек
Вы нарушаете DRY, создавая ненужный класс BatteryCharger, который каким-то образом вызовет изменение состояния батареи. Таким образом, BatteryCharger примет некоторый вход, который затем сразу же перейдет к батарее.
Кевин Клайн
9

Избегайте двойных значений

Вы сознательно выбрали слово, которое имеет более одного значения, и первое решение - это проблема. Есть масса слов, которые проблематичны для программистов. Другой пример будет phone. Вы можете phoneкого-то, или вы могли бы иметь phoneв своем кармане.

Используйте геттеры и сеттеры

Стандартным наименованием для большинства объектов являются методы получения / настройки свойств.

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

Свойства являются состояниями, а не существительными

Я думаю, что вы ошибаетесь, классифицируя свойства объекта как существительные, а переменные также могут рассматриваться как состояния. Это государства, имеющие отношение к локальной сфере их существования.

Вы могли бы описать значение, которое они считают существительным, но я не уверен, что это верно во всех случаях.

В терминологии ООП свойства объекта описывают состояние этого объекта. В вашем случае Batteryэто объект, и это Chargeсостояние. Так что это будет свойство объекта, но это зависит от контекста его использования.

Если вам нужно уметь работать Chargeот батареи, а также знать, какой у нее ток Charge, то у вас проблема.

Использование Scope для реализации контекста

Контекст - это то, что прояснит, какое значение слова вы намереваетесь передать методом или свойством. Scope устанавливает доступность свойства / метода извне объекта.

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

Методы - это глаголы

Вы можете описать метод объекта как глагол, но слово action лучше подходит. В терминологии ООП вы выполняете действия над объектами, используя их методы. Нехорошо модифицировать свойство объекта снаружи объекта. Предпочтительно вызывать метод, который выполняет необходимые действия, которые вызывают изменение его состояния.

Слово Chargeэто глагол, но это также существительное. При использовании для вызова метода действия становится ясно, что глагол используется Battery.Charge(....).

Но контекст очень важен. Хотя слово Charge()это глагол, оно не так значимо, как startCharging().

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

Простые методы одно слово часто явно не излагают свои действия четко, но есть некоторые случаи , как openи closeгде мало объяснения требуется.

Так что на самом деле нет правильного ответа относительно того, как называть эти типы свойств / методов. За исключением того, что вам нужно использовать вышеупомянутые методы с умом, чтобы не было путаницы.

Reactgular
источник
2
Для записи, клиент - это тот, кто использует неоднозначную терминологию. Я не создавал этот беспорядок. :-) Я поднял вопрос, так как думал, что, возможно, я не единственный человек, попадающий в такую ​​ситуацию. У вас есть несколько правильных точек в вашем ответе. В данном конкретном случае мы не работаем над гранулярностью времени, что StartCharge()и EndCharge()подразумевает. Фактически, эта терминология привела бы к значительным накладным расходам при работе с аккумуляторной системой. На каждом интервале это может быть Charge()либо Discharge().
1
Основная задача заключается в том, чтобы сохранить внутреннюю семантику программирования синхронной с терминологией, которую использует клиент. Chargeоказывается наиболее легко понять неоднозначное слово для этой области. Есть несколько других.
6

Добавьте к ним глаголы, которые сделают их глаголом или существительным.

Battery.doCharge()

Battery.getCharge()
Юрген Пауль
источник
4

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

FrustratedWithFormsDesigner
источник
Не уверен в этом. Поскольку мы используем C #, мы можем объявить get и set для Property вместо необходимости использовать отдельные функции. Независимо от этого, я беспокоюсь о техническом обслуживании и о том, как оно будет выглядеть, когда я забыл, что я написал. Не 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

В большинстве случаев добавление вспомогательного глагола, наречия или прилагательного достаточно для их различения и может помочь в понимании. В случае использования Charge и Charge () на аккумуляторе, делающем это, DeltaCharge () может показать, что это функция, которая может обрабатывать как зарядку, так и разрядку.

Дельта (в случаях, когда есть изменения, но неоднозначные) - это модификатор, который я использую и рекомендую всем остальным для передачи изменений в состоянии (даже если глагол полуочевиден).

Джефф Лангемайер
источник
0

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

Или вы можете просто использовать то же имя и позволить IDE справиться с этим. В любом случае создание более длинного или другого имени может быть столь же запутанным в долгосрочной перспективе.

Ryathal
источник
+1 за уникальный взгляд на ответ. К сожалению, венгерская нотация явно многословна в соответствии с нашими рекомендациями по стилю кода. Это не меняет потенциального достоинства вашего ответа, просто я не могу использовать его как свое реальное решение.