Булев метод именования положительный против отрицательного


44

Должны ли булевы методы всегда принимать утвердительную форму, даже если они будут использоваться только в отрицательной форме?

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

В итоге, мне if(!affirmative)легче читать, чем if(negative). У меня есть коллега, который не согласен, мысли?

Первая форма:

int entity_id = 42;
if(!entity_exists(entity_id)) create_entity(entity_id);

Вторая форма:

int entity_id = 42;
if(entity_not_exist(entity_id)) create_entity(entity_id);

3
C ++? как насчетif (not entity_exists(entity_id))
Кос


To-May-To-Ma-To. Честно говоря, я пропустил этот !символ так много раз, что заставлял меня неправильно понимать код, пока я не перечитал его снова. Так что я, вероятно, больше согласен с вашим коллегой. Мне нравится форма, которая оценивается как истинная, когда вы ее изучаете.
Берин Лорич,

Просто хотел присоединиться, чтобы сказать, что это if (!exists) create()может рассматриваться как плохая практика во многих языках / фреймворках, так как это, как правило, не является потокобезопасным. Обычно предпочтительный подход заключается в вызове create()и обработке определенных исключений или кодов возврата, говорящих о том, что объект уже существует. Это, конечно, не ответ на реальный вопрос (вот почему это только комментарий).
Jullealgon

Ответы:


61

Должны ли булевы методы всегда принимать утвердительную форму, даже если они будут использоваться только в отрицательной форме?

Создание правил о таких вещах кажется немного сложным - я не хотел бы видеть руководство в документе по стандартам кодирования, в котором говорится, что вы не должны использовать отрицательные имена для логических свойств . Но, исходя из личного стиля, я думаю, что попытка сохранить положительные имена может быть хорошим идеалом. Тем не менее, я думаю, что это также хорошо, чтобы избежать необходимости этого тощего и легко пропустить !. Часто можно найти способы превратить отрицательное имя в положительное:

  • accountHasCharges
  • accountIsClear(так же, как !accountHasCharges)

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

  • isComplete // Хорошо
  • isNotComplete //! isComplete обычно лучше
  • isIncomplete // может иметь смысл, если «неполное» является известным состоянием объекта
  • !isNotComplete // какой ужас
  • !isNotComplete == 0 // может привести к постоянному отпуску

5
«Я не хотел бы видеть руководство в документе стандартов кодирования, которое говорит, что вы не должны использовать отрицательные имена для логических свойств ». - Я просто оставлю это здесь ...
AakashM

16
Вы забыли!isNotIncomplete
Бен Ли

Так бы противоположностью entity_existsбыть entity_should_be_createdentity_not_exists)? Или, возможно, entity_missingсогласно предложению Дэна?
ADTC

1
Именно здесь в документе стандартов кодирования может использоваться слово «предпочитать», а не «должен» или «должен».
Уэйн Конрад

15

Я согласен, что утвердительно легче читать. Вы можете попробовать

Третья форма

int entity_id = 42;
if (entity_is_missing(entity_id)) create_entity(entity_id);

или

Четвертый класс

int entity_id = 42;
if (is_entity_missing(entity_id)) create_entity(entity_id);

2

Это также зависит от того, как будет использоваться ваш метод. Если он будет использоваться как в положительных, так и в отрицательных случаях, например,

if (!entity_exists(entity_id)) create_entity(entity_id);

if (entity_exists(entity_id)) publish_entity(entity_id);

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

Но если он используется ТОЛЬКО в отрицательном случае, то допустимо следующее (может быть, даже желательно)

if (entity_not_exists(entity_id)) create_entity(entity_id);

или даже лучше перефразировать это, чтобы быть более позитивным

if (entity_is_absent(entity_id)) create_entity(entity_id);
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.