Каждый разработчик ежедневно сталкивается с ситуациями, когда ему приходится писать код, который выполняется на основе некоторого условия, и каждое условие в конечном итоге разрешается в логическое значение. Когда условия становятся достаточно сложными, чтобы быть частью конструкций управления потоком, таких как ifs..while..whens, мы склонны извлекать их в метод с осмысленным именем, которое обычно принимает форму isXYZ()
, где XYZ — наиболее логичное имя для условия.
Когда я как разработчик сталкиваюсь с методом, который выглядит как isXYZ()
, я интуитивно предполагаю, что этот метод возвращает true, если XYZ истинно. Здесь XYZ должен быть как можно ближе к делу, например isAccountActive()
, isTokenValid()
, isUserEligible()
.
Еще один способ написания этих функций состоит в том, чтобы возвращать истину, когда XYZ ложно, что приводит к чему-то вроде этого: isNotXYZ()
, примерами таких функций могут быть: isAccountInactive()
, isTokenInvalid()
или isUserInEligible()
. Если подумать, эти методы могут легко заменить любой метод isXYZ, например, блок If, проверяющий isUserEligible, может легко вместить isUserInEligible с помощью простого оператора отрицания.
Можно просто предположить, что это безобидное изменение (а оно действительно безобидно, если говорить о производительности и корректности кода). Но если мы подумаем о расширяемости и повторном использовании, представьте себе случай, когда я хочу использовать isUserInEligible в ситуации, когда я хочу выполнить блок кода, только если пользователь имеет право, я бы написал что-то вроде этого:
!isUserInEligible()
Чтоааааааааааааааааааааааааа??? Отрицание отрицания??
Хотя это в равной степени верно, мне (и некоторым другим разработчикам) субъективно читать гораздо труднее. Чаще всего булевы условия являются достоверным источником появления ошибки, и я предпочел бы выбрать читаемое имя метода, чем запутаться из-за глупых условий.
Итак, в заключение, булевы методы должны выглядеть с положительной стороны жизни — должны иметь имена, которые выражают, верно ли какое-то условие, а не выражают, если какое-то условие «не» верно. Короче говоря, логические методы должны быть оптимистичными.
– Чинмай
https://geeknarrator.com