Каждый разработчик ежедневно сталкивается с ситуациями, когда ему приходится писать код, который выполняется на основе некоторого условия, и каждое условие в конечном итоге разрешается в логическое значение. Когда условия становятся достаточно сложными, чтобы быть частью конструкций управления потоком, таких как 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