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

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

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

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

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

Один из примеров с battery. А batteryимеет, chargeи вы также можете charge()аккумулятор.

Я думаю , что наличие как Battery.Chargeи Battery.Charge(value)будет сбивать с толку разработчиков в будущем.

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

У меня вопрос, есть ли другой / лучший способ справиться с этим конфликтом в соглашении об именах?

Некоторое дополнительное чтение на предмете. Никто на самом деле не обратился к конкретному моему вопросу.

• Содержательные и краткие рекомендации по присвоению имен
• Соглашения об именах переменных
• Выбранный ответ от https://softwareengineering.stackexchange.com/questions/14169/what-naming-guidelines-do-you-follow

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

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

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

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

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

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

Вы сознательно выбрали слово, которое имеет более одного значения, и первое решение - это проблема. Есть масса слов, которые проблематичны для программистов. Другой пример будет 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где мало объяснения требуется.

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

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

Battery.doCharge()

Battery.getCharge()

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

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

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

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

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