在这几天，看到了之前经常关注的一个论坛上解释了函数返回类型设计的一些问题，我觉得说的很透彻，这里分享给大家！
　　不知从什么时候起，对函数返回值，有一种下意识的认识：“0”是成功、非“0”表示失败。
　　先讲个故事，就是项目移植时的一段小插曲——
　　近期工作，使用一款新的芯片进行开发。移植过程中需调用的函数库接口，接口有uint32_t类型的返回值。根据手册的说明，函数返回值“0”表示成功，“-1”表示失败。这里的返回值比较简单，仅有成功、失败两种，一般采用“if（！ret）{成功}else{失败}”判断。就这样，移植过程中，该芯片函数库绝大部分的接口返回值都是这两种，处理结果时图省事也就把“if（！ret）{成功}else{失败}”复制粘贴了。
　　意外出现了，当我调用库的“比对”函数接口时结果一直错误，返回值总是“1”，也就是“真”的逻辑，于是上层接口一直对应用层向用户报错。翻阅手册检查了接口的输入参数，怀疑其他接口处理的数据错误，又检查该接口之前的其他被调用接口。可偏偏，手册里对本接口描述的返回值说明，因排版而放在下一页，你如何都无法想到，这里的函数返回值，竟然是成功时返回“1”，失败返回“0”！
　　回想起检查这一整个执行流程时，几乎花了一中午时间，万万没想到竟然忽略这个细节，真是“踏破铁鞋无觅处，得来全不费工夫”！
　　总而言之，芯片厂商提供的函数库接口，返回值设计的过于简单，也没达到完全的统一规范。说到底，只能怪自己对这么重要的细节没有留意到位。作为开发者，要多从自身找原因，确保自己的每一个环节不出异常。即使面对多么棘手的代码，你都可以应对自如。
　　此事对自己的教训只能是不要忽略细节。但有时候本可以做好的事情，为什么不一口气做到位呢！对于函数返回值的定义，其实可以做到相对规范一些，统一起来，对自己对他人都是有帮助的。
　　返回值可以有两种，一个是函数执行结束得到的数据，还有就是函a数执行结束的状态结果。
　　返回数据就是把传入参数做了某一个运算后得到的结果;返回状态结果，主要指示函数是否正确执行。
　　返回数据，这种返回值不能表示是否正确执行，只能认为，有返回值了就是正确执行了。所以这样的函数执行时，不该有参数正确性判断，不管传什么样的参数应该都能执行。
　　简单的例子就是一个求和运算函数：
　　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开发里，同样是枚举类型的返回值，为什么不扩展枚举的成员来表示复杂多样的执行结果呢。
　　同时在编写函数时，利用枚举类型定义函数的返回类型，对开发而言，查看枚举类型中的成员表，可快速知道，函数的执行结果可能会有什么样的状态，至少有个预期的判断。
　　这样一来就可以为每个模块、每个层封装好的函数，设计对应的返回类型。
　　总结，说到底这些都只是开发者日常的编程习惯罢了，或者接口设计的规范。返回值的类型定义，谈不上的对和错，对错只有在程序执行的时候，判断的依据选择。但是一个好的编码规范、统一的对照表，这对代码的维护和迭代，都有非常关键的作用！