轉：從開源項目學習 C 語言基本的編碼規則

從開源項目學習 C 語言基本的編碼規則

每一個項目都有本身的風格指南：一組有關怎樣爲那個項目編碼約定。一些經理選擇基本的編碼規則，另外一些經理則更偏好很是高級的規則，對許多項目而言則沒有特定的編碼規則，項目中的每一個開發者使用他本身的風格。

全部代碼都保持一致風格的大型庫，更容易讓人理解。

有許多資源是關於能讓人採起的更好的編碼規則的，咱們能夠經過如下方式學到好的編碼規則：

• 閱讀書或雜誌
• 瀏覽網站
• 與同事交流
• 參加培訓

另外一個更有趣的方法是經過研究一個成熟的知名開源項目來得知其開發者是怎樣編寫代碼的。對於C語言來講，Linux內核是個不錯的選擇。

對初級甚至中級的C開發者而言，可能不太容易深刻到Linux內核的代碼中，可是咱們的目標不必定得是對它的源碼作出貢獻，而是探索它是怎樣實現的。

讓咱們以來自Linux源碼中的一個函數實現爲例：

這段代碼看起來很是乾淨，實際上這個函數

• 僅有幾行代碼
• 簽名定義得好
• 註釋寫得好
• 縮進安排得好
• 變量名很是清晰

一樣的功能能夠被另外一個開發者如下面這種方式實現

編碼風格對源碼的可讀性影響甚巨，投入一些時間培訓開發者以及週期性評審代碼總有利於輕鬆地維護和升級代碼。

讓咱們使用CppDepend深刻到Linux內核的源碼中，發現一些它的開發者們採用的編碼規則。

模塊化

模塊化是一種提高使用不一樣獨立部分構建軟件的程度的設計技巧，你能夠輕鬆地管理維護模塊化的代碼。

對於像C這種沒有名字空間（namespace）、組件（component）或者類（class）等邏輯構件的過程語言，咱們可使用目錄和文件實現模塊化。

下面是一些可能的情形：

• 把全部的代碼放在一個目錄中
•  分離出與一個模塊或子模塊有關的文件，再放入一個特定的目錄

Linux內核使用目錄和子目錄來模塊化核心源碼：

封裝

封裝是指隱藏一份實現內部的功能與數據。在C中，封裝是經過使用關鍵字static實現的。這些實體稱爲文件域的函數和變量。

讓咱們經過執行下面的CQLinq查詢語句查找一下全部的靜態函數：

使用Metric視圖，咱們能夠清楚地看到有多少個函數是靜態的。在Metric視圖中，代碼庫由樹形圖（Treemap）描述。樹形圖（Treemap）是一種使用嵌套矩形來展現樹結構數據的方法。CppDepend中樹形圖使用的樹結構就是一般的代碼層次結構：

• 項目包含目錄
• 目錄包含文件
• 文件包含結構體，函數和變量

樹形圖視圖爲描述一條CQLinq請求的結果提供了一種有用的方式，因此咱們可以可視化地看到與該請求有關的類型。

正如咱們所見，許多函數都聲明爲靜態的

如今咱們來查詢靜態域：

和函數的標記同樣，許多變量都聲明爲靜態屬性。

在Linux內核源碼中，只要函數和變量對於文件域而言是私有的，就使用封裝的手法。

使用結構體存儲你的數據模型

在C編程中，函數使用變量達到不一樣的處理要求，這些變量能夠是：

• 靜態變量
•  全局變量
• 局部變量
• 結構體變量

每一個項目都有一些能夠被不少源文件使用的數據模型，可使用全局變量，但這不是好的解決方案，更推薦使用結構體對數據分組。

讓咱們搜索一下屬於基本類型的全局變量：

僅有幾個變量與該查詢匹配，也許咱們能夠把這些變量中的一些分組到結構體中，例如（elfcorehdr_addr and elfcorehdr_size），或者是（pm_freezing and pm_nosig_freezing）這樣。

讓函數短小而幹練

下面是來自linux編碼風格網頁的一份關於函數長度的建議：

函數應該短小而幹練，而且一個函數只作一件事。它們應該剛好佔據一屏到兩屏（咱們都知道ISO/ANSI標準屏幕的大小爲80×24），只作一件事而且作得很好。

一個函數的最大長度與它的複雜程度和縮進層級成反比。因此，若是你有一個概念上簡單的函數，這個函數包含着冗長的（可是簡單）case語句，而每一個case分支都對應着爲不一樣狀況而不得不進行簡單處理，那麼這個函數長點也沒多大關係。

讓咱們找找多於30行的函數：

多於30行的方法僅有幾個。

函數參數的個數

擁有多於8個參數的函數調用起來可能很傷神，還可能下降函數的性能。一個替代方案是提供一個專職傳參的結構體。

僅有2個方法的參數多於8個。

局部變量的個數

方法的局部變量超過8個，會讓方法難以理解，也難以維護。超過15個就很是複雜，這時應該拆分紅兩個更小的方法（使用工具自動生成的除外）。

僅僅5個函數的局部變量超過15個。

避免定義複雜的函數

有許多度量複雜函數的指標，上面提到的代碼行數、參數個數和局部變量個數是基本的。

還有些其餘有趣的指標：

• 環路複雜度在過程軟件中是一個廣爲使用的指標，等於一個過程能夠接納的決議的個數。
• 嵌套深度是一個定義在方法上的指標，該指標與方法體中最深嵌套做用域成正比。
• 最大嵌套循環等於嵌套在一個函數中最深循環層級。

這些指標的可接受最大值更多依賴於團隊的選擇，並無標準參考值。

讓咱們找找可能須要重構的函數：

只有不多幾個能夠被認爲是複雜的函數。

命名約定

命名約定沒有標準，每一個項目經理均可以選擇他們認爲更好的規範，重要的是遵照選擇的約定，讓項目擁有一致的命名。

例如在Linux中，結構體必須以小寫字母開頭，咱們能夠驗證一下這條規則在整個核心代碼中是否成立，執行下面的查詢：

僅有4個結構體以「_」代替小寫字母開頭。

縮進

縮進很是有利於讓代碼容易閱讀，下面這段摘自linux編碼風格網頁的文字，說明了隱藏在使用縮進背後的動機。

 

原理闡釋：縮進背後總體思想是爲了清楚地定義一個控制塊的開始與結束。特別是當你已經持續對着屏幕長達20個小時的時候，你更容易發現縮進是怎樣發揮功效的（若是你有大量的縮進）

當前，有的人會聲稱，八字符的縮進會讓代碼行右端伸太遠，這會是代碼在80字符寬度的終端屏幕上難以閱讀。對此的答案是：若是你須要多於3級縮進的話，無論怎麼說，你已經陷入囹圄，你應該修改你的程序。

結論

探究一些知名開源項目老是有利於提升你的編程技巧，不必下載生成該項目，你從——好比說——GitHub上就能夠發現這些代碼。