问题描述
|
我有一些程序大量使用带有错误代码枚举的库。
0(枚举的第一个值)是成功而1是失败的类型。在某些情况下,我有自己的帮助程序函数,这些函数返回bool指示错误,而在其他情况下,我冒泡了错误枚举。不幸的是,有时我会误以为是另一件事,但事情会失败。
你会推荐什么?我是否缺少在gcc上会在这些情况下发出警告的警告?
附言返回与我的代码完全无关的错误代码感觉很奇怪,尽管我猜我可以返回-1或其他无效值。
解决方法
这是一个坏主意吗?不,您应该做有意义的事情,而不是遵循某些抽象规则(类似规则几乎永远无法满足您将要遇到的所有情况)。
我避免麻烦的一种方法是确保所有返回布尔值的函数读起来都像正确的英语,例如
isEmpty()
,userFlaggedExit()
或hasContent()
。这与我的普通动词-名词构造(例如updateTables()
,deleteAccount()
或crashProgram()
)不同。
对于一个返回布尔值的函数,该布尔值通常表示该函数的动词或名词会遵循该动词-名词构造,我倾向于使用deleteAccountWorked()
或successfulTableUpdate()
之类的东西。
在所有这些返回布尔值的情况下,我都可以构造一个易于阅读的if
语句:
if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...
等等。
对于非布尔返回函数,我仍然遵循惯例,即0可以,而其他所有值都是某种错误。智能功能名称的使用通常意味着很明显哪个是哪个。
但是请记住,这就是我的解决方案。它可能对别人也可能不起作用。
, 我会说,在您控制的应用程序部分以及组成外部API的部分中,选择一种错误处理并坚持下去。哪种类型不太重要,但要保持一致。否则,在您的代码上工作的人将不知道会发生什么,甚至您自己,当您在一年左右的时间回到代码时,也会抓到自己的头;)
, 如果按照零==错误方案进行标准化,则可以像这样构造测试来混合和匹配enum和bool:
err = some_func();
如果!err ...
由于第一个枚举的计算结果为零,并且成功的情况也与布尔错误返回完全匹配。
但是,通常最好返回一个int(或枚举),因为这样可以扩展返回的错误代码,而无需修改调用代码。
, 我不会说这是一个坏习惯。
如果只需要返回true
/false
,并且没有其他选择(and11ѭ和false
就足够说明了),则无需创建吨enum
-s。
另外,如果您的函数命名为OK,那么您的\“错误\”将更少
例如-IsBlaBla
-期望返回true
。如果您有[Do|On]Reload
,重新加载可能会由于多种原因而失败,因此so10ѭ是可以预期的。 IsConnected
和Connect
等相同。
, 恕我直言,功能命名在这里有帮助。
例如。对于返回布尔值is_foo_bar(...)的函数,对于返回成功或错误代码的函数do_foo_bar(...)。