不知从什么时候起，对函数返回值，有一种下意识的认识：“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开发里，同样是枚举类型的返回值，为什么不扩展枚举的成员来表示复杂多样的执行结果呢。
同时在编写函数时，利用枚举类型定义函数的返回类型，对开发而言，查看枚举类型中的成员表，可快速知道，函数的执行结果可能会有什么样的状态，至少有个预期的判断。
这样一来就可以为每个模块、每个层封装好的函数，设计对应的返回类型。
总结，说到底这些都只是开发者日常的编程习惯罢了，或者接口设计的规范。返回值的类型定义，谈不上绝对的对和错，对错只有在程序执行的时候，判断的依据选择。但是一个好的编码规范、统一的对照表，这对代码的维护和迭代，都有非常关键的作用！
★★★★★推荐文章
《【嵌入式编程】平台大小端存储差异解决办法》
《嵌入式硬件通信接口-使用RingBuffer处理数据(二)详细设计过程》
《嵌入式硬件通信接口-使用RingBuffer处理数据(一)》
《快速开发MQTT（一）电子工程师眼中的MQTT》
《快速开发MQTT（二）初识MQTT》
《MQTT客户端搭建-最清晰的MQTT协议架构》
《MQTT服务端搭建-最快方式验证自己开发的客户端》
★★★★★相似文章
《嵌入式硬件通信接口协议-UART（五）数据包设计与解析》
《嵌入式硬件通信接口协议-UART（四）设计起止式的应用层协议》
《嵌入式硬件通信接口协议-UART（三）快速使用串口及应用》
《嵌入式硬件通信接口协议-UART（二）不同电气规范下的标准》
《嵌入式硬件通信接口协议-UART（一）协议基础》
《嵌入式硬件通信接口协议-SPI（二）分层架构设计模拟接口》
《嵌入式硬件通信接口协议-SPI（一）协议基础》
★★★★★扩展阅读
《【硬件电路】AltiumDesigner18规则检查含义》
《【硬件电路】N沟道、P沟道MOS管基本原理与应用案例》
