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

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

先講個(gè)故事，就是項(xiàng)目移植時(shí)的一段小插曲——

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

意外出現(xiàn)了，當(dāng)我調(diào)用庫的“比對”函數(shù)接口時(shí)結(jié)果一直錯(cuò)誤，返回值總是“1”，也就是“真”的邏輯，于是上層接口一直對應(yīng)用層向用戶報(bào)錯(cuò)。翻閱手冊檢查了接口的輸入?yún)?shù)，懷疑其他接口處理的數(shù)據(jù)錯(cuò)誤，又檢查該接口之前的其他被調(diào)用接口?？善謨岳飳Ρ窘涌诿枋龅姆祷刂嫡f明，因排版而放在下一頁，你如何都無法想到，這里的函數(shù)返回值，竟然是成功時(shí)返回“1”，失敗返回“0”!

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

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

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

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

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

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

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

uint16_t func_sum(uint8_t val1, uint8_tval2)

{

Return (val1+val2);

}

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

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

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

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

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

定義返回狀態(tài)結(jié)果，可以設(shè)計(jì)為：

布爾型(bool)的真、假;

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

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

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

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

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

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

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

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

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

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

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