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

不知從什么時候起，對函數(shù)返回值，有一種下意識的認識：“0”是成功、非“0”表示失敗。

先講個故事，就是項目移植時的一段小插曲——

近期工作，使用一款新的芯片進行開發(fā)。移植過程中需調(diào)用官方的函數(shù)庫接口，接口有uint32_t類型的返回值。根據(jù)手冊的說明，函數(shù)返回值“0”表示成功，“-1”表示失敗。這里的返回值比較簡單，僅有成功、失敗兩種，一般采用“if(!ret){成功}else{失敗}”判斷。就這樣，移植過程中，該芯片函數(shù)庫絕大部分的接口返回值都是這兩種，處理結果時圖省事也就把“if(!ret){成功}else{失敗}”復制粘貼了。

意外出現(xiàn)了，當我調(diào)用庫的“比對”函數(shù)接口時結果一直錯誤，返回值總是“1”，也就是“真”的邏輯，于是上層接口一直對應用層向用戶報錯。翻閱手冊檢查了接口的輸入?yún)?shù)，懷疑其他接口處理的數(shù)據(jù)錯誤，又檢查該接口之前的其他被調(diào)用接口。可偏偏，手冊里對本接口描述的返回值說明，因排版而放在下一頁，你如何都無法想到，這里的函數(shù)返回值，竟然是成功時返回“1”，失敗返回“0”!

回想起檢查這一整個執(zhí)行流程時，幾乎花了一中午時間，萬萬沒想到竟然忽略這個細節(jié)，真是“踏破鐵鞋無覓處，得來全不費工夫”!

總而言之，芯片廠商提供的函數(shù)庫接口，返回值設計的過于簡單，也沒達到完全的統(tǒng)一規(guī)范。說到底，只能怪自己對這么重要的細節(jié)沒有留意到位。作為開發(fā)者，要多從自身找原因，確保自己的每一個環(huán)節(jié)不出異常。即使面對多么棘手的代碼，你都可以應對自如。

此事對自己的教訓只能是不要忽略細節(jié)。但有時候本可以做好的事情，為什么不一口氣做到位呢!對于函數(shù)返回值的定義，其實可以做到相對規(guī)范一些，統(tǒng)一起來，對自己對他人都是有幫助的。

返回值可以有兩種，一個是函數(shù)執(zhí)行結束得到的數(shù)據(jù)，還有就是函數(shù)執(zhí)行結束的狀態(tài)結果。

返回數(shù)據(jù)就是把傳入?yún)?shù)做了某一個運算后得到的結果;返回狀態(tài)結果，主要指示函數(shù)是否正確執(zhí)行。

返回數(shù)據(jù)，這種返回值不能表示是否正確執(zhí)行，只能認為，有返回值了就是正確執(zhí)行了。所以這樣的函數(shù)執(zhí)行時，不該有參數(shù)正確性判斷，不管傳什么樣的參數(shù)應該都能執(zhí)行。

最簡單的例子就是一個求和運算函數(shù)：

uint16_t func_sum(uint8_t val1, uint8_tval2)

{

Return (val1+val2);

}

這樣的返回值就是函數(shù)執(zhí)行后得到的數(shù)據(jù)結果。這個沒有必要做太多的討論。

返回狀態(tài)結果，比如在上文提到的芯片官方的庫接口，利用“0”和“-1”表示執(zhí)行后成功或失敗的結果。

在《嵌入式硬件通信接口-使用RingBuffer處理數(shù)據(jù)(二)詳細設計過程》一文中的“讀一個字節(jié)”、“讀多個字節(jié)”和后續(xù)的其他函數(shù)，執(zhí)行結束后返回的狀態(tài)結果有成功和不成功的其他多個狀態(tài)，這些個狀態(tài)都是rb_ret_t枚舉類型里的成員。

比如寫多字節(jié)接口，如果執(zhí)行失敗，可能是參數(shù)錯誤、空間不足，這時非常有必要對不同的錯誤返回不同的狀態(tài)結果，因此返回碼不再是“0”和“-1”了，而是零和非零的其他值。

如何設計返回狀態(tài)，也是有講究的。如果因為一時的沖動，一閉眼一跺腳就把返回狀態(tài)碼給定下來，并且同一層、同一類的接口，狀態(tài)結果定義的還不一致，那就太隨便了，這樣的接口封裝出來，如果沒有逐個對接口說明，指不定哪天蒙了自己也坑到別人。

定義返回狀態(tài)結果，可以設計為：

布爾型(bool)的真、假;

枚舉類型的各種狀態(tài)碼;

布爾型，在C++中使用，只有真、假兩個狀態(tài)，如果在基于C的嵌入式開發(fā)里使用，還需要重新定義。

類似于STM32的V3.5.0標準庫里的三個枚舉定義，每個枚舉都只定義了兩種狀態(tài)，也可稱之為布爾類型。

在設計自己的系統(tǒng)時，也可以直接使用這種枚舉來定義函數(shù)返回的狀態(tài)結果。

但是這里的枚舉中，成員的值“0”表示失敗、非“0”表示成功。這種方式定義的，失敗只有一個情況，對后續(xù)的應用擴展也是個麻煩，比如不同的失敗原因，如何體現(xiàn)到不同的返回狀態(tài)結果，因此再考慮引入枚舉類型的各種狀態(tài)碼。

“0”表示成功、非“0”表示失敗，這個思維也符合計算機“0”為假、非“0”為真的邏輯特點。在程序執(zhí)行時，成功了就是成功了，沒必要去考慮為什么執(zhí)行成功了，但是失敗的時候，總是存在問題導致失敗，這時候就需要對失敗做分析，那么失敗原因很多，對計算機而言，邏輯“真”也很多，1、2、3、…、99、…、N只要不是“0”，就是非“0”的邏輯“真”。

枚舉類型的各種狀態(tài)碼，主要是為了解決，在出現(xiàn)不同的失敗原因時，返回錯誤碼，可以方便上層應用對參數(shù)進行檢查，嘗試調(diào)整參數(shù)重新調(diào)用接口再次執(zhí)行;或者對錯誤碼分別處理后展示在用戶交互接口，提示用戶執(zhí)行某一功能時返回的狀態(tài)。

可見在C開發(fā)里，同樣是枚舉類型的返回值，為什么不擴展枚舉的成員來表示復雜多樣的執(zhí)行結果呢。

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

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

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