Должны ли булевы методы всегда принимать утвердительную форму, даже если они будут использоваться только в отрицательной форме?
Скажем, я хотел проверить, существует ли сущность, прежде чем создавать ее, я утверждаю, что первая форма ниже лучше второй формы, независимо от того, используется ли метод когда-либо в утвердительной форме.
В итоге, мне 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);
if (not entity_exists(entity_id))
!
символ так много раз, что заставлял меня неправильно понимать код, пока я не перечитал его снова. Так что я, вероятно, больше согласен с вашим коллегой. Мне нравится форма, которая оценивается как истинная, когда вы ее изучаете.if (!exists) create()
может рассматриваться как плохая практика во многих языках / фреймворках, так как это, как правило, не является потокобезопасным. Обычно предпочтительный подход заключается в вызовеcreate()
и обработке определенных исключений или кодов возврата, говорящих о том, что объект уже существует. Это, конечно, не ответ на реальный вопрос (вот почему это только комментарий).Ответы:
Создание правил о таких вещах кажется немного сложным - я не хотел бы видеть руководство в документе по стандартам кодирования, в котором говорится, что вы не должны использовать отрицательные имена для логических свойств . Но, исходя из личного стиля, я думаю, что попытка сохранить положительные имена может быть хорошим идеалом. Тем не менее, я думаю, что это также хорошо, чтобы избежать необходимости этого тощего и легко пропустить
!
. Часто можно найти способы превратить отрицательное имя в положительное:accountHasCharges
accountIsClear
(так же, как!accountHasCharges
)Ясность является наиболее важным фактором, и хорошая причина избегать использования отрицательных имен методов заключается в том, что они могут привести к двойным отрицаниям или хуже:
isComplete
// ХорошоisNotComplete
//! isComplete обычно лучшеisIncomplete
// может иметь смысл, если «неполное» является известным состоянием объекта!isNotComplete
// какой ужас!isNotComplete == 0
// может привести к постоянному отпускуисточник
!isNotIncomplete
entity_exists
бытьentity_should_be_created
(аentity_not_exists
)? Или, возможно,entity_missing
согласно предложению Дэна?Я согласен, что утвердительно легче читать. Вы можете попробовать
Третья форма
или
Четвертый класс
источник
Это также зависит от того, как будет использоваться ваш метод. Если он будет использоваться как в положительных, так и в отрицательных случаях, например,
Тогда имя метода должно быть утвердительным, как указано выше. Если вы не уверены, как это будет использоваться, то придерживайтесь вышеизложенного.
Но если он используется ТОЛЬКО в отрицательном случае, то допустимо следующее (может быть, даже желательно)
или даже лучше перефразировать это, чтобы быть более позитивным
источник