好記性不如爛筆頭o(^▽^)o

C語言的藝術之函數

1、1個函數僅完成1件功能

1個函數實現多個功能給開發、使用、保護都帶來很大的困難。
將沒有關聯或關聯很弱的語句放到同1函數中，會致使函數職責不明確，難以理解，難以測試和改動。

案例：realloc
??在標準C語言中，realloc是1個典型的不良設計。這個函數基本功能是重新分配內存，但它承當了太多的其他任務：如果傳入的指針參數為NULL就分配內存，如果傳入的大小參數為0就釋放內存，如果可行則就地重新分配，如果不行則移到其他地方分配。如果沒有足夠可用的內存用來完成重新分配（擴大原來的內存塊或分配新的內存塊），則返回NULL，而原來的內存塊保持不變。這個函數不容易擴大，容易致使問題。例以下面代碼容易致使內存泄漏：

??如果沒有足夠可用的內存用來完成重新分配，函數返回為NULL，致使buffer原來指向的內存被丟失。

2、重復代碼應當盡量提煉成函數

重復代碼提煉成函數可以帶來保護本錢的下降。

??項目組應當使用代碼重復度檢查工具，在延續集成環境中延續檢查代碼重復度指標變化趨勢，并對新增重復代碼及時重構。當1段代碼重復兩次時，即應斟酌消除重復，當代碼重復超過3次時，應當立刻著手消除重復。
??1般情況下，可以通過提煉函數的情勢消除重復代碼。

3、避免函數太長，新增函數盡可能不超過50行（非空非注釋行）

僅對新增函數做要求，對已有函數修改時，建議不增加代碼行。

太長的函數常常意味著函數功能不單1，過于復雜。
函數的有效代碼行數，即NBNC（非空非注釋行）應當在[1，50]區間。
業界普遍認為1個函數的代碼行不要超過1個屏幕，避免來回翻頁影響瀏覽。
例外：某些實現算法的函數，由于算法的聚合性與功能的全面性，可能會超過50行。

4、避免函數的代碼塊嵌套過深，新增函數的代碼塊嵌套不超過4層

僅對新增函數做要求，對已有的代碼建議不增加嵌套層次。

??函數的代碼塊嵌套深度指的是函數中的代碼控制塊（例如：if、for、while、switch等）之間相互包括的深度。每級嵌套都會增加瀏覽代碼時的腦力消耗，由于需要在頭腦里保護1個“棧”（比如，進入條件語句、進入循環……）。應當做進1步的功能分解，從而避免使代碼的瀏覽者1次記住太多的上下文。優秀代碼參考值：[1, 4]。

5、可重入函數應避免使用同享變量；若需要使用，則應通過互斥手段（關中斷、信號量）對其加以保護

可重入函數是指可能被多個任務并發調用的函數。在多任務操作系統中，函數具有可重入性是多個任務可以共用此函數的必要條件。同享變量指的全局變量和static變量。

??編寫C語言的可重入函數時，不應使用static局部變量，否則必須經過特殊處理，才能使函數具有可重入性。
示例：函數square_exam返回g_exam平方值。那末以下函數不具有可重入性。

??此函數若被多個線程調用的話，其結果多是未知的，由于當（**）語句剛履行完后，另外1個使用本函數的線程可能正好被激活，那末當新激活的線程履行到此函數時，將使g_exam賦于另外一個不同的para值，所以當控制重新回到“temp =square_exam ( )”后，計算出的temp極可能不是料想中的結果。此函數應以下改進。

6、對參數的合法性檢查，由調用者負責還是由接口函數負責，應在項目組/模塊內應統1規定。缺省由調用者負責

對模塊間接口函數的參數的合法性檢查這1問題，常常有兩個極端現象，即：要末是調用者和被調用者對參數均不作合法性檢查，結果就遺漏了合法性檢查這1必要的處理進程，造成問題隱患；要末就是調用者和被調用者均對參數進行合法性檢查，這類情況雖不會造成問題，但產生了冗余代碼，下降了效力。

7、對函數的毛病返回碼要全面處理

1個函數（標準庫中的函數/第3方庫函數/用戶定義的函數）能夠提供1些唆使毛病產生的方法。這可以通過使用毛病標記、特殊的返回數據或其他手段，不管甚么時候函數提供了這樣的機制，調用程序應當在函數返回時立刻檢查毛病唆使。

8、設計高扇入，公道扇出（小于7）的函數

扇出是指1個函數直接調用（控制）其它函數的數目，而扇入是指有多少上級函數調用它。

??扇出過大，表明函數過分復雜，需要控制和調和過量的下級函數；而扇出太小，例如：總是1，表明函數的調用層次可能過量，這樣不利于程序瀏覽和函數結構的分析，并且程序運行時會對系統資源如堆?？臻g等造成壓力。通常函數比較公道的扇出（調度函數除外）通常是3~5。
??扇出太大，1般是由于缺少中間層次，可適當增加中間層次的函數。扇出太小，可把下級函數進1步分解多個函數，或合并到上級函數中。固然分解或合并函數時，不能改變要實現的功能，也不能背背函數間的獨立性。
??扇入越大，表明使用此函數的上級函數越多，這樣的函數使用效力高，但不能背背函數間的獨立性而單純地尋求高扇入。公共模塊中的函數及底層函數應當有較高的扇入。
??較良好的軟件結構通常是頂層函數的扇出較高，中層函數的扇出較少，而底層函數則扇入到公共模塊中。

9、廢棄代碼（沒有被調用的函數和變量)要及時清除

說明：程序中的廢棄代碼不但占用額外的空間，而且還常常影響程序的功能與性能，極可能給程序的測試、保護等造成沒必要要的麻煩。

10、函數不變參數使用const

不變的值更容易于理解/跟蹤和分析，把const作為默許選項，在編譯時會對其進行檢查，使代碼更牢固/更安全。

11、函數應避免使用全局變量、靜態局部變量和I/O操作，不可避免的地方應集中使用

帶有內部“存儲器”的函數的功能多是不可預測的，由于它的輸出可能取決于內部存儲器（如某標記）的狀態。這樣的函數既不容易于理解又不利于測試和保護。在C語言中，函數的static局部變量是函數的內部存儲器，有可能使函數的功能不可預測。

12、檢查函數所有非參數輸入的有效性，如數據文件、公共變量等

函數的輸入主要有兩種：1種是參數輸入；另外一種是全局變量、數據文件的輸入，即非參數輸入。函數在使用輸入參數之前，應進行有效性檢查。

13、函數的參數個數不超過5個

函數的參數過量，會使得該函數易于受外部（其他部份的代碼）變化的影響，從而影響保護工作。函數的參數過量同時也會增大測試的工作量。
函數的參數個數不要超過5個，如果超過了建議拆分為不同函數。

14、除打印類函數外，不要使用可變長參函數

可變長參函數的處理進程比較復雜容易引入毛病，而且性能也比較低，使用過量的可變長參函數將致使函數的保護難度大大增加。

15、在源文件范圍內聲明和定義的所有函數，除非外部可見，否則應當增加static關鍵字

如果1個函數只是在同1文件中的其他地方調用，那末就用static聲明。使用static確保只是在聲明它的文件中是可見的，并且避免了和其他文件或庫中的相同標識符產生混淆的可能性。

??建議定義1個STATIC宏，在調試階段，將STATIC定義為static，版本發布時，改成空，以便于后續的打熱補釘等操作。