不知从什么时候起，对函数返回值，有一种下意识的认识：“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开发里，同样是枚举类型的返回值，为什么不扩展枚举的成员来表示复杂多样的执行结果呢。

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

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

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