混合 bool 和 ret 代码是不是一个坏主意答案

【问题标题】：Is it a bad idea to mix bool and ret codes混合 bool 和 ret 代码是不是一个坏主意
【发布时间】：2011-09-13 17:50:08
【问题描述】：

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

0（枚举的第一个值）是成功，1是失败的那种。在某些情况下，我有自己的帮助函数，它们返回指示错误的 bool，在其他情况下，我会冒泡错误枚举。不幸的是，有时我把一个误认为另一个，事情就失败了。

你会推荐什么？我是否错过了一些关于 gcc 的警告，这些警告会在这些情况下发出警告？

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

【问题讨论】：

标签： c boolean return-value typeerror return-code

【解决方案1】：

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

【讨论】：

【解决方案2】：

如果对零 == 错误方案进行标准化，则可以混合和匹配 enum 和 bool，如果您像这样构建测试：

err = some_func(); 如果！错误...

由于第一个枚举的计算结果为零，而且成功案例也与布尔错误返回完美匹配。

但是，通常最好返回一个 int（或 enum），因为这允许在不修改调用代码的情况下扩展返回的错误代码。

【讨论】：

这不是零！=错误吗？因为对于枚举而言，拥有 1 个 ok 代码和 n 错误代码是有意义的，而不是相反。
好吧，不，op 成功为 0（实际上很常见），所以 !err ...“做一些事情”按预期工作。
非常常见，因为枚举默认从 0 开始。
更像 return_code != success 但有时我可能会做实际_a_bool != success_value_which_is_equal_to_zero 。命名变量 var_bool 太难看了。

【解决方案3】：

恕我直言，函数命名在这里有所帮助。

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

【讨论】：

请注意，这些暗示着不同的行为。 do_xyz() 通常表示函数有副作用，而is_xyz() 通常用于不会导致（可观察到的）状态变化的谓词。
@efotinis：是的，也是。巧合的是，我几乎所有返回 bool 的函数都是没有副作用的函数。通常当一个函数有副作用时，有多种方法会失败，因此错误代码是比布尔值更好的选择。无论如何，paxdiablo 的答案似乎更详细地说明了我的想法。

【解决方案4】：

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

没有必要创建大量的enum-s，如果你只需要返回true/false，并且你没有其他选择（true和false已经足够解释了）。

另外，如果你的函数被命名为 OK，你的“错误”就会更少

例如 - IsBlaBla - 期望返回 true。如果您有[Do|On]Reload，则重新加载可能会由于多种原因而失败，因此预计会出现enum。 IsConnected 和 Connect 等也一样。

【讨论】：

枚举是来自外部库的错误枚举。
啊，我明白了，我错过了那部分。

【解决方案5】：

这是个坏主意吗？不，你应该做有意义的事，而不是遵循一些抽象的规则（这些规则几乎从迎合你将遇到的所有情况）。

我避免麻烦的一种方法是确保所有布尔返回函数读起来都像正确的英语，例如isEmpty()、userFlaggedExit() 或hasContent()。这与我的普通动词-名词结构不同，例如 updateTables()、deleteAccount() 或 crashProgram()。

对于返回布尔值的函数，该函数通常遵循动词-名词结构，我倾向于使用 deleteAccountWorked() 或 successfulTableUpdate() 之类的函数成功或失败。

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

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

等等。

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

但请记住，这是我的解决方案。它可能适用于其他人，也可能不适用。

【讨论】：