C程序代碼風格

    下面這篇文章是linux內核中Documentation/CodingStyle文件，覺得挺有意思，就順手把它譯出來了，因為雖然這只是“l(fā)inux”的代碼風格，但優(yōu)秀的C程序風格大致無二。特別是emacs相關的東西，肯定有誤譯，請多指正。

    Linux內核編碼風格

    這篇簡短的文章描述了Linux內核首選的編碼風格。編碼風格是很個人化的東西，我不會把自己的觀點強加給任何人。但是，Linux內核的代碼畢竟是我必須有能力維護的，因此我寧愿它的編碼風格是我喜歡的。請至少考慮一下這一點。
   
    首先，我建議打印一份《GNU編碼標準》，不要閱讀它。燒掉它，它不過是象征性的姿態(tài)。
   
    然后，請看： 

    第 1 章： 縮進

    Tabs(制表符)是8個字符的大小，因此縮進也應該是8個字符的大小。有些叛逆主張試圖把縮進變成4個(甚至是2個！)字符的長度，這就好象試圖把PI(案，圓周率)定義成3是一樣的。
   
    依據：縮進背后的思想是:清楚地定義一個控制塊從哪里開始，到哪里結束。尤其是在你連續(xù)不斷的盯了20個小時的屏幕后，如果你有大尺寸的縮進。你將更容易發(fā)現縮進的好處。
   
    現在，有些人說8個字符大小的縮進導致代碼太偏右了，并且在一個80字符寬的終端屏幕上看著很不舒服。對這個問題的回答是：如果你有超過3個級別的縮進，你就有點犯糊涂了，應當修改你的程序。
   
    簡而言之，8個字符的縮進使程序更易讀，而且當你把功能隱藏的太深時，多層次的縮進還會對此很直觀的給出警告。要留心這種警告信息。 
    
    第 2 章： 放置花括號

    C程序中另一個要主意的就是花括號的放置。與縮進尺寸不同的是，關于如何放置花括號沒有技術上的理由。但是，首選的方法是象先知Brain Kernighan和Dennis Ritchie展現的那樣：把左括號放在行尾，右括號放在行首。也就是：
   
   if (x is true) {
      we do y
   }
   
    然而，還有另外一種情況，就是函數：函數應當把左右括號都放在行首。也就是：
   
   int function(int x)
   {
      body of function
   }
   
    叛逆的人們所在皆有。他們說，這樣會導致…嗯，不一致性(案，指函數的花括號使用與其他情況不統(tǒng)一)。但是所有正確思考的人都知道：(1) K&R是正確的；(2) K&R還是正確的。 而且，函數與別任何東西都不一樣(在C語言中你沒法隱藏它)。
   
    注意，右括號所在的行不應當有其它東西，除非跟隨著一個條件判斷。也就是do-while語句中的“while”和if-else語句中的“else”。象這樣：
   
   do {
      body of do-loop
   } while (condition);
   
和：
   
   if (x == y) {
      ..
   } else if (x > y) {
      ...
   } else {
      ....
   }
   
    依據： K&R。
   
    而且，注意這種花括號的放置減少了空行的數目，并沒損害可讀性。因此，當屏幕上不可以有很多空行時(試想25行的終端屏幕)，你就有更多的空行來安插注釋。 
    
    第 3 章： 命名

    C是一門樸素的語言，你使用的命名也應該這樣。與Modula-2和Pascal程序員不同，C程序員不使用諸如“ThisVariableIsATemporaryCounter”這樣“聰明”的名字。C程序員應該叫它“tmp”，這寫起來更簡單，也不會更難懂。 
 
    然而，當面對復雜情況時就有些棘手，給全局變量取一個描述性的名字是必要的。把一個全局函數叫做“foo”是一種目光短淺的行為。
   
    全局變量(只當你確實需要時才用)應該有描述性的名字，全局函數也一樣。如果你有一個統(tǒng)計當前用戶個數的函數，應當把它命名為“count_active_user()”或者簡單點些的類似名稱，不應該命名為“cntusr()”。
   
    把函數類型寫進函數名(即所謂的“匈牙利命名法”)簡直就是大腦有問題──編譯器總是知道函數的類型并且能加以檢查，這種命名法只會弄糊涂程序員自己。怪不得微軟總是制造充滿bug的程序。
   
    局部變量的名字應該盡量短，而且說到點子上。如果你有個普通的整型循環(huán)計數變量，應當命名為“i”。命名為“l(fā)oop_counter”并不能帶來任何成效，如果它不被誤解的話(案，這里的言外之意是說，如果被誤解就更慘了)。與此類似，“tmp”可以作為一個用來存儲任何類型臨時值的變量的名字。
   
    如果你害怕弄混淆局部變量(s)的名字，你就面臨著另一個問題，也叫作“函數增長荷爾蒙失調綜合癥”。請參考下一章。 
    
    第 4 章： 函數

    函數應當短而精美，而且只做一件事。它們應當占滿1或2個屏幕(就象我們知道的那樣，ISO/ANSI的屏幕大小是80X24)，只做一件事并且把它做好。
 
    一個函數的最大長度與它的復雜度和縮進級別成反比。所以，如果如果你有一個概念上簡單(案，“簡單”是simple而不是easy)的函數，它恰恰包含著一個很長的case語句，這樣你不得不為不同的情況準備不懂的處理，那么這樣的長函數是沒問題的。
   
    然而，如果你有一個復雜的函數，你猜想一個并非天才的高一學生可能看不懂得這個函數，你就應當努力把它減縮得更接近前面提到的最大函數長度限制。可以使用一些輔助函數，給它們取描述性的名字(如果你認為這些輔助函數的調用是性能關鍵的，可以讓編譯器把它們內聯進來，這比在單個函數內完成所有的事情通常要好些)。
   
    對函數還存在另一個測量標準：局部變量的數目。這不該超過5到10個，否則你可能會弄錯。應當重新考慮這個函數，把它分解成小片。人類的大腦一般能同時記住7個不同的東西，超過這個數目就會犯糊涂。或許你認為自己很聰明，那么請你理解一下從現在開始的2周時間你都做什么了。 

    第 5 章：注釋

    注釋是有用的，但過量的注釋則是有害的。不要試圖在注釋中解釋你的代碼是如何工作的：把代碼是如何工作的視為一件顯然的事情會更好些，而且，給糟糕的代碼作注釋則是在浪費時間。

    通常，你愿意自己的注釋說出代碼是做什么的，而不是如何做。還有，盡量避免在函數體內作注釋：如果函數很復雜，你很可能需要分開來注釋，回頭到第4章去看看吧。你可以給一段代碼──漂亮的或丑陋的──作注釋以引起注意或警告，但是不要過量。取而代之，應當把注釋放在函數首部，告訴人們該函數作什么，而不是為什么這樣做。 

    第 6 章：你把事情弄亂了

    好吧，我們來看看。很可能有長期使用UNIX的人告訴過你，“GNU emacs”能自動為你格式化C程序源代碼，你注意到這是真的，它確實能做到，但是缺省情況下它的用處遠遠小于期望值──鍵入無數的monkeys到GNU emacs中絕不可能造出好的程序。
 
    因此，你可以或者刪除GNU emacs，或者對它進行理智的配置。對于后者，可以把下面的行粘貼到你的.emacs文件中：
   
   (defun linux-c-mode ()
   "C mode with adjusted defaults for use with the Linux kernel."
   (interactive)
   (c-mode)
   (c-set-style "K&R")
   (setq c-basic-offset 8))
   
    這將會定義一個把C代碼弄成linux風格的命令。當hacking一個模塊時，如果你把“-*- linux-c -*-”放到了最初的兩行，這個模塊將被自動調用。而且，如果你打算每當在/usr/src/linux下編輯源文件時就自動調用它，也許你會把下面的命令：
   (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)
            auto-mode-alist))
    添加進你的.emacs文件。
   
    但是，即使你沒能讓emacs正確做到格式化，也并非將就此一無所有：還有“indent”程序呢。
   
    嗯，再提醒一下，GNU indent跟GNU emacs有同樣的毛病，這就需要你給它一些命令行選項。然而，這不是很糟糕的事，因為即使是GNU indent也承認K&R的權威性(GNU的人不是魔鬼，他們只是在這里太過嚴格了，以致于誤導人)，所以你可以只需給indent這樣的選項：“-kr -i8”(表示“K&R風格，8個字符的縮進”)。
   
    “indent”程序有很多選項，特別是當為重排過的程序作注釋的時候，你需要看一下它的手冊。記住：“indent”可不是修正糟糕程序的萬能鑰匙。 
    
    第 7 章： 配置文件(configuration-files)

    對配置選項來說(arch/xxx/config.in和所有的Config.in文件)，使用不同的縮進風格。
 
    若代碼中的縮進級別為3，配置選項就應該為2,這樣可以暗示出依賴關系。后者只是用于bool/tristate(即二態(tài)/三態(tài))的選項。對其它情況用常識就行了。舉例來說：

   if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
      tristate 'Apply nitroglycerine inside the keyboard (DANGEROUS)' CONFIG_BOOM
      if [ "$CONFIG_BOOM" != "n" ]; then
         bool '  Output nice messages when you explode' CONFIG_CHEER
      fi
   fi

    通常CONFIG_EXPERIMENTAL應當在所有不穩(wěn)定的選項的周圍出現。所有已知會破壞數據的選項(如文件系統(tǒng)的實驗性的寫支持功能)應當被標記為(DANGEROUS)，其他實驗性的選項應當被標記為(EXPERIMENTAL)。 
    

    第 8 章： 數據結構

    假如數據結構在其被創(chuàng)建/銷毀的線程環(huán)境(案：這里說的線程是一個執(zhí)行實體，可能是進程、內核線程或其它)之外還具有可見性，那么他們都該有引用計數。 在內核中沒有垃圾收集機制(而且內核之外的垃圾收集也是緩慢而低效的)，這意味著你絕對應該為每一次使用進行引用計數。
   
    引用計數意味著你可以避開鎖，還能允許多個線程并行訪問該數據結構──而且不用擔心僅僅因為訪問數據結構的線程睡眠了一會兒或者干別的去了，它們就會消失。
   
    注意，鎖不是引用計數的替代品。鎖是用來保持數據結構的一致性的，而引用計數是一種內存管理技術。通常二者都需要，而且不會彼此混淆。 下面這篇文章是linux內核中Documentation/CodingStyle文件，覺得挺有意思，就順手把它譯出來了，因為雖然這只是“l(fā)inux”的代碼風格，但優(yōu)秀的C程序風格大致無二。特別是emacs相關的東西，肯定有誤譯，請多指正。