![]() |
1
4
拾取 一 每一个返回类型的模式和坚持它,否则你会让自己疯狂。根据长期为平台建立的约定来建模您的模式:
测试返回值对C程序员来说是个祸害。如果失败很少,并且您可以编写一个中央处理程序,请考虑使用
exception macro package
可以指示故障,使用
|
![]() |
2
4
为什么不使用C标准库使用的方法?哦,等等… |
![]() |
3
3
不是你问题的真实答案,而是一些你可能会感兴趣的随机评论:
|
![]() |
4
2
我能想到的一个条件是,上面的方法可能会失败,一个函数可以返回任何值,包括-1,比如一个函数加两个有符号的数字。 在这种情况下,测试-1肯定是个坏主意。
如果发生故障,我最好设置一个C标准提供的全局错误条件标志,格式为
|
![]() |
5
2
因为不能失败的决定论。使用更具体(bool)返回类型的是/否响应有助于保持一致性。对于更高级别的接口,您可能需要考虑返回或更新特定于系统的消息传递/结果详细结构。 我对0始终成功的偏好基于以下观点:
|
![]() |
6
0
你在想这件事,这件事有很长的路要走。如果你想出一个或两个规则——或者甚至更多,如果它们有意义(你可能需要不止一个规则——就像你提到的,你可能想处理返回的指针不同于其他东西),我认为你会比许多商店更好。 我个人喜欢用0来表示失败,用非0来表示成功,但我没有足够的理由坚持这一点。我可以理解这种哲学,它可能想扭转这种感觉,这样你就可以返回失败的不同原因。 最重要的是要遵循指导方针。更好的做法是制定有文件证明的指导方针(我相信,有了合理的指导方针,人们更容易遵守指导方针)。就像我说的,你在考虑这些事情,这一事实让你比其他许多人都强。 |
![]() |
7
0
这是一个偏好问题,但我注意到的是不一致性。考虑使用pre-c99编译器 #define SUCCESS 1 #define ERROR 0 然后任何返回int的函数,返回其中一个或另一个以最小化混淆并严格遵守它。同样,根据并考虑到开发团队,坚持他们的标准。 在C99之前的编译器中,int为零是假的,任何大于零的都是真的。这取决于编译器的标准是什么,如果是c99,则使用stdbool的bool类型。 C的最大优点是你可以使用你的个人风格,但是如果需要团队的努力,就要坚持团队制定的标准并认真遵循它,即使在你离开这个工作之后,另一个程序员也会感激你。 保持一致。 希望这有帮助, 最好的问候, 汤姆。 |
![]() |
8
0
许多C标准库使用该策略只在成功时返回true(或1),在失败时返回false(或0),并将结果存储在传入位置。比“it failed”更具体的错误代码存储在特殊变量errno中。
像这样的东西
|