侵权投诉
当前位置:

OFweek电子工程网

开发工具/算法

正文

函数返回类型设计

导读: 返回数据,这种返回值不能表示是否正确执行,只能认为,有返回值了就是正确执行了。所以这样的函数执行时,不该有参数正确性判断,不管传什么样的参数应该都能执行。

不知从什么时候起,对函数返回值,有一种下意识的认识:“0”是成功、非“0”表示失败。

先讲个故事,就是项目移植时的一段小插曲——

近期工作,使用一款新的芯片进行开发。移植过程中需调用官方的函数库接口,接口有uint32_t类型的返回值。根据手册的说明,函数返回值“0”表示成功,“-1”表示失败。这里的返回值比较简单,仅有成功、失败两种,一般采用“if(!ret){成功}else{失败}”判断。就这样,移植过程中,该芯片函数库绝大部分的接口返回值都是这两种,处理结果时图省事也就把“if(!ret){成功}else{失败}”复制粘贴了。

意外出现了,当我调用库的“比对”函数接口时结果一直错误,返回值总是“1”,也就是“真”的逻辑,于是上层接口一直对应用层向用户报错。翻阅手册检查了接口的输入参数,怀疑其他接口处理的数据错误,又检查该接口之前的其他被调用接口。可偏偏,手册里对本接口描述的返回值说明,因排版而放在下一页,你如何都无法想到,这里的函数返回值,竟然是成功时返回“1”,失败返回“0”!

回想起检查这一整个执行流程时,几乎花了一中午时间,万万没想到竟然忽略这个细节,真是“踏破铁鞋无觅处,得来全不费工夫”!

总而言之,芯片厂商提供的函数库接口,返回值设计的过于简单,也没达到完全的统一规范。说到底,只能怪自己对这么重要的细节没有留意到位。作为开发者,要多从自身找原因,确保自己的每一个环节不出异常。即使面对多么棘手的代码,你都可以应对自如。

此事对自己的教训只能是不要忽略细节。但有时候本可以做好的事情,为什么不一口气做到位呢!对于函数返回值的定义,其实可以做到相对规范一些,统一起来,对自己对他人都是有帮助的。

返回值可以有两种,一个是函数执行结束得到的数据,还有就是函数执行结束的状态结果。

返回数据就是把传入参数做了某一个运算后得到的结果;返回状态结果,主要指示函数是否正确执行。

返回数据,这种返回值不能表示是否正确执行,只能认为,有返回值了就是正确执行了。所以这样的函数执行时,不该有参数正确性判断,不管传什么样的参数应该都能执行。

最简单的例子就是一个求和运算函数:

uint16_t func_sum(uint8_t val1, uint8_tval2)

Return (val1+val2);

这样的返回值就是函数执行后得到的数据结果。这个没有必要做太多的讨论。

返回状态结果,比如在上文提到的芯片官方的库接口,利用“0”和“-1”表示执行后成功或失败的结果。

在《嵌入式硬件通信接口-使用RingBuffer处理数据(二)详细设计过程》一文中的“读一个字节”、“读多个字节”和后续的其他函数,执行结束后返回的状态结果有成功和不成功的其他多个状态,这些个状态都是rb_ret_t枚举类型里的成员。

比如写多字节接口,如果执行失败,可能是参数错误、空间不足,这时非常有必要对不同的错误返回不同的状态结果,因此返回码不再是“0”和“-1”了,而是零和非零的其他值。

如何设计返回状态,也是有讲究的。如果因为一时的冲动,一闭眼一跺脚就把返回状态码给定下来,并且同一层、同一类的接口,状态结果定义的还不一致,那就太随便了,这样的接口封装出来,如果没有逐个对接口说明,指不定哪天蒙了自己也坑到别人。

定义返回状态结果,可以设计为:

布尔型(bool)的真、假;

枚举类型的各种状态码;

布尔型,在C++中使用,只有真、假两个状态,如果在基于C的嵌入式开发里使用,还需要重新定义。

类似于STM32的V3.5.0标准库里的三个枚举定义,每个枚举都只定义了两种状态,也可称之为布尔类型。

在设计自己的系统时,也可以直接使用这种枚举来定义函数返回的状态结果。

但是这里的枚举中,成员的值“0”表示失败、非“0”表示成功。这种方式定义的,失败只有一个情况,对后续的应用扩展也是个麻烦,比如不同的失败原因,如何体现到不同的返回状态结果,因此再考虑引入枚举类型的各种状态码。

“0”表示成功、非“0”表示失败,这个思维也符合计算机“0”为假、非“0”为真的逻辑特点。在程序执行时,成功了就是成功了,没必要去考虑为什么执行成功了,但是失败的时候,总是存在问题导致失败,这时候就需要对失败做分析,那么失败原因很多,对计算机而言,逻辑“真”也很多,1、2、3、…、99、…、N只要不是“0”,就是非“0”的逻辑“真”。

枚举类型的各种状态码,主要是为了解决,在出现不同的失败原因时,返回错误码,可以方便上层应用对参数进行检查,尝试调整参数重新调用接口再次执行;或者对错误码分别处理后展示在用户交互接口,提示用户执行某一功能时返回的状态。

可见在C开发里,同样是枚举类型的返回值,为什么不扩展枚举的成员来表示复杂多样的执行结果呢。

同时在编写函数时,利用枚举类型定义函数的返回类型,对开发而言,查看枚举类型中的成员表,可快速知道,函数的执行结果可能会有什么样的状态,至少有个预期的判断。

这样一来就可以为每个模块、每个层封装好的函数,设计对应的返回类型。

总结,说到底这些都只是开发者日常的编程习惯罢了,或者接口设计的规范。返回值的类型定义,谈不上绝对的对和错,对错只有在程序执行的时候,判断的依据选择。但是一个好的编码规范、统一的对照表,这对代码的维护和迭代,都有非常关键的作用!

声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

我来说两句

(共0条评论,0人参与)

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号