Плохо ли смешивать логические и рет-коды?

Это плохая идея? Нет, вы должны делать то, что имеет смысл, а не следовать какому-то абстрактному правилу (которое почти никогда не подходит для всех ситуаций, с которыми вы все равно столкнетесь).

Один из способов избежать проблем — убедиться, что все функции, возвращающие логические значения, читаются как на правильном английском языке, например, isEmpty(), userFlaggedExit() или hasContent(). Это отличается от моих обычных конструкций глагол-существительное, таких как updateTables(), deleteAccount() или crashProgram().

Для функции, которая возвращает логическое значение, указывающее на успех или неудачу функции, которая обычно следует за этой конструкцией глагол-существительное, я обычно использую что-то вроде deleteAccountWorked() или successfulTableUpdate().

Во всех случаях, когда возвращаются логические значения, я могу создать легко читаемый оператор if:

if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...

И так далее.

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

Но имейте в виду, что это моё решение. Это может или не может работать для других людей.

Я бы сказал, что в тех частях приложения, которыми вы управляете, и в частях, составляющих ваш внешний API, выберите один тип обработки ошибок и придерживайтесь его. Какой тип менее важен, но будьте последовательны. В противном случае люди, работающие над вашим кодом, не будут знать, чего ожидать, и даже вы сами будете чесать голову, когда вернетесь к коду через год или около того;)

Если стандартизировать схему с нулевой == ошибкой, вы можете смешивать и сопоставлять как enum, так и bool, если вы построите свои тесты следующим образом:

ошибка = некоторые_функции(); если !ошибся...

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

Однако, как правило, лучше возвращать целое число (или перечисление), так как это позволяет расширить возвращаемые коды ошибок без модификации вызывающего кода.

Я бы не сказал, что это плохая практика.

Нет необходимости создавать тонны enum, если вам просто нужно вернуть true/false, и у вас нет других вариантов (и true и false достаточно пояснены).

Кроме того, если ваши функции названы OK, у вас будет меньше «ошибок».

Например - IsBlaBla - ожидает возврата true. Если у вас [Do|On]Reload, перезагрузка может завершиться неудачей по многим причинам, поэтому следует ожидать enum. То же самое для IsConnected и Connect и т. д.

ИМХО, здесь помогает именование функций.

Например. для функций, возвращающих логическое значение, is_foo_bar(...) или для функций, возвращающих код успеха или ошибки, do_foo_bar(...).