Как правильнее будет использовать оператор if?

Question

[oftywave]

задался таким вопросом, а имеется ли вообще в этом смысл. вот сам код

//пример и не более того.
std::string a = "a";

// то как я делаю сейчас
if (a == "a")
   success;
else
   not_success;

// но есть вариант проще и собственно работа одинаковая

if (a !=  "a")
   not_success;

success 
// do something

я понимаю, что это на вкус и цвет, но все же интересно ваше мнение.

Comments

[Василий Банников]

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

[Денис Загаевский]

Василий Банников, все люди думают по-разному.

[Василий Банников]

Денис Загаевский, ладно. "Как в тз"

[Денис Загаевский]

Василий Банников, и кто тебе тз до ифа расписывает?

[Василий Банников]

Денис Загаевский, ну как как.
"Если в БД нет пользователя с данным id, то клиенту возвращается ответ с кодом 404" (или наоборот)
"Если в БД есть пользователь, то возвращается ответ с кодом 200 и json, иначе 404"
От формулировки я бы и отталкивался при написании кода.

Answer 1

[galaxy]

Зависит от содержания success/not_success.
Если внутри not_success, например, нет оператора выхода (return, throw, хоть goto), то во втором случае выполнится сначала not_success, а потом success.

Comments

[oftywave]

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

[Евгений Шатунов]

oftywave, в общем смысле тебе правильно нравится. Для человека интуитивно понятнее проверка на эквивалентность, а инверсия практически всегда заставляет задуматься над ее поведением.
Чаще всего трудно читаемые конструкции стоит заменять на поясняющие константы.
Например, если думать что функция всегда должна работать по успешному сценарию и только иногда возвращать ошибку, именно по состоянию ошибки и стоит ветвиться. Такой подход называется Early Return.

const bool is_failed = a != "a";
if( is_failed ) [[unlikely]]
{
    // failure
    return ... ;
}

// success

Тут используется атрибут из C++20 для того, чтобы пометить переход в тело ветвления как менее приоритетный перед остальным кодом. Это поможет транслятору сгенерировать более линейный код для успешного пути функции, а тело //failure он поместит в отдельное место, куда прыгнет в случае is_failed == true.

[oftywave]

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

Answer 2

[res2001]

Всегда, когда это возможно, использую второй вариант - это позволяет избежать лишних фигурных скобок, а как следствие лишней вложенности, отступов и т.п., код становится более читабельный и простой.
Но, конечно, в этом случае, в теле if должна быть передача управления куда-то (на обработчик ошибок, return и т.п.).
Часто делаю такую конструкцию:

do {
...
if(result == error) break;
...
} while(0);
if(result == error) {
обработка ошибок
}

В этом случае обработка ошибок находится в одном месте. Кроме того do..while(0) позволяет не использовать goto - вместо него используется break. Часто видел подобную схему в около системных сервисах и утилитах, но с использованием goto. У меня аллергия на goto, поэтому предпочитаю заворачивать в do..while(0).

Answer 3

[Александр Ананьев]

Имхо, второй вариант предпочтительнее, если success - это большой кусок кода или в нем есть дополнительные проверки условий (вложенные if).