（總結）編寫高質量c語言代碼 第5 章糖果機界面

1.要使用戶不容易忽視錯誤狀況不要在正常地返回值中隱藏錯誤代碼

2. ，那些常常把錯誤值和有效數據混雜在一塊兒返回的程序員，會習慣性地設計出象 realloc 這樣的界面.

3. （「不要在返回值中隱 藏錯誤」）

4. 我認爲找出這些暗藏陷阱的惟一辦法是停下來思考所作的設計。這樣作 的最佳途徑是檢查輸入和輸出的各類可能組合，尋找可能引發問題的反作用。

5. 要竭盡全力地尋找並消除函數界面中的缺陷

6 . realloc 的另外一個問題是：咱們知道傳遞給realloc 的多是無用信息，可是由於其定 義如此通用使它很難防範無效的參數。若是錯誤地給它傳遞了NULL 指針，合法；若是錯誤 地給它傳遞了爲零的塊長也合法。

7. 無論出於什麼樣的理由編寫了多功能的函數，都要把它分解爲不一樣的功能。對於 realloc 來講，就是要分解出擴大內存塊、縮小內存塊、分配內存塊和釋放內存塊。把realloc 分解爲四個不一樣的函數.

8. 不要編寫多種功能集於一身的函數 爲了對參數進行更強的確認，要編寫功能單一的函數.

9. 正象明確的輸出令人容易搞清函數的結果同樣，明確的輸入亦令人容易理解函數要作 的事情，它對必須閱讀和理解別人程序的維護人員極有價值。

10. 從靠近錯誤的斷言開始查錯，要比從錯誤的輸出開始查錯速度更快。

11 . 從「無錯」的觀點，若是函數的參數越界或者無心義，那麼即便能被智能地處理，仍然 應該被視爲非法的輸入。

12. 程序員處理大小（或計數）爲O 參數一般是由於

他們可以處理而不是應該處理。若是所編函數有大小參數，那麼並不必定非得對大小爲0

進行處理，而要問本身：「程序員用大小爲0 的參數調用這個函數的額度是多少？」若是根

本或者幾乎不會這麼調用，那就不要對大小爲0 進行處理，而要加上相應的斷言。 要記住，

消除限制就是消除捕獲相應錯誤的機會，因此一個良好的準則是，一開始就要爲函數的輸入

選擇嚴格的定義，並最大限度地利用斷言。這樣，若是事後發現某個限制過於苛刻，能夠把

它去掉而不至於影響到程序的其它部分。

13. 不要模棱兩可，要明確地定義函數的參數。

14.返回錯誤就意味着對錯誤進行處理， 若是發現本身在設計函數時要返回一個錯誤代碼，那麼要先停下來問本身：是否還有其 它的設計方法能夠不用返回該錯誤狀況

15. 編寫函數使其在給定有效的輸入狀況下不會失敗

16. 並不是只有把輸出都合在一塊兒和返回沒必要要的錯誤代碼纔會 致使複雜的代碼。有時引發代碼複雜化的緣由徹底因爲粗心而忽視了相應的函數調用「讀’ 的效果。

17. 程 序員在幾十年前就已經知道應該在程序中避免使用莫名其妙的數字。有名的常量不只可使 代碼更可讀，並且使代碼更可移植。

18. 使程序在調用點明瞭易懂；要避免布爾參數

19. 編寫註解突出可能的異常狀況

20.對一個函數界面的設計要從如下方面進行考慮：1.函數的傳入參數是否合理，2.函數的返回值是否合理3.函數的調用是否方便