在這幾天，看到了之前經常關注的一個論壇上解釋了函數返回類型設計的一些問題，我覺得說的很透徹，這里分享給大家！

不知從什么時候起，對函數返回值，有一種下意識的認識：“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開發里，同樣是枚舉類型的返回值，為什么不擴展枚舉的成員來表示復雜多樣的執行結果呢。

同時在編寫函數時，利用枚舉類型定義函數的返回類型，對開發而言，查看枚舉類型中的成員表，可快速知道，函數的執行結果可能會有什么樣的狀態，至少有個預期的判斷。

這樣一來就可以為每個模塊、每個層封裝好的函數，設計對應的返回類型。

總結，說到底這些都只是開發者日常的編程習慣罷了，或者接口設計的規范。返回值的類型定義，談不上絕對的對和錯，對錯只有在程序執行的時候，判斷的依據選擇。但是一個好的編碼規范、統一的對照表，這對代碼的維護和迭代，都有非常關鍵的作用！

責任編輯：ct