C 混合使用bool和ret代码是个坏主意吗

我有一些程序大量使用错误代码枚举库

0（枚举的第一个值）表示成功，1表示失败的类型。在某些情况下，我有自己的helper函数返回bool指示错误，在其他情况下，我冒泡错误枚举。不幸的是，有时我把一个错当成另一个，事情就失败了

你推荐什么？我是否遗漏了gcc上的一些警告，在这些情况下会发出警告

---

另外，返回一个与我的代码完全无关的错误代码感觉很奇怪，尽管我想我可以返回-1或其他一些无效值

在您控制的应用程序部分，以及构成外部API的部分，我会说，选择一种错误处理类型并坚持使用它。哪种类型不太重要，但要保持一致。否则，编写您的代码的人将不知道会发生什么，甚至您自己也会在一年左右的时间内重新编写代码时挠头；）

如果在零==错误方案上进行标准化，那么如果您像这样构造测试，您可以混合和匹配enum和bool：

err=某些函数（）； 如果！呃

由于第一个枚举的计算结果为零，并且也是成功案例，因此它与bool错误返回完全匹配

---

但是，通常最好返回int（或enum），因为这样可以扩展返回的错误代码，而无需修改调用代码。

IMHO函数命名有助于此

---

例如，对于返回布尔值的函数，is_foo_bar（…），或者对于返回成功或错误代码的函数，do_foo_bar（…）。

我不会说，这是一种不好的做法

如果只需要返回

true

/

false

，并且没有其他选项（并且

true

和

false

足够解释），则无需创建大量的

enum

-s

此外，如果函数名为OK，则“错误”会减少

---

例如-

IsBlaBla

-期望返回

true

。如果您有

[Do | On]重新加载

，则重新加载可能会由于多种原因失败，因此

枚举

是可以预期的。连接的

和
连接的
也是一样的。
这是个坏主意吗？不，你应该做有意义的事情，而不是遵循一些抽象的规则（类似的规则几乎永远不会满足你将遇到的所有情况）

我避免麻烦的一种方法是确保所有布尔返回函数都像正确的英语一样阅读，例如
isEmpty（）
，
userFlaggedExit（）
或
hascantent（）
。这不同于我的普通动词-名词结构，如
updateTables（）
，
deleteCount（）
或
crashProgram（）

对于一个返回布尔值的函数，它指示一个通常遵循动词-名词结构的函数的成功或失败，我倾向于使用类似于
deleteAccountWorked（）
或
successfulTableUpdate（）
的内容

在所有这些布尔返回情况下，我可以构造一个易于阅读的
if
语句：

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

等等

对于非布尔返回函数，我仍然遵循约定，即0是可以的，而所有其他值都是某种类型的错误。智能函数名的使用通常意味着很明显哪个是哪个


但请记住，这是我的解决方案。它可能对其他人起作用，也可能对其他人不起作用。
但请注意，这意味着不同的行为
do_xyz（）
通常表示函数有副作用，而
is_xyz（）
通常用于不会导致（可观察到）状态更改的谓词。@efotini:是的，也是这样。巧合的是，几乎所有返回bool的函数都是没有副作用的函数。通常，当一个函数有副作用时，有多种失败方式，因此错误代码比布尔代码更好。不管怎么说，paxdiablo的答案似乎更详细地阐述了我的想法。枚举是来自外部库的错误枚举。啊，我明白了，我错过了这一部分。这难道不是零吗！=错误？因为对于一个枚举来说，有1个ok代码和n个错误代码是有意义的，而不是相反。不，op有0作为成功（实际上很常见），所以！犯错误“做一些事情”可以正常工作。非常常见，因为枚举默认从0开始。更像是返回代码！=成功，但有时我可能真的会成功成功值等于零。命名变量var bool太难看了。