這篇短小的文章是對Linux內核編程風格的建議. 編程風格非常的個性化,而且,我並不想將我的觀點強加給任何人,但是為了變於維護,我不得不提出這個觀點. 詳情如下: 在最開始,我應該寫出GNU 編程風格的標准而不用理會它. 不要理會他們,它只是一個符號表情而已. 好,讓我們開始吧! 第一章: 縮進格式 Tab 是 8 個字符,於是縮進也是8個字符.有很多怪異的風格,他們將縮進格式定義為4個字符(設置為2個字符!)的深度,這就象試圖將PI定義為3一樣讓人難以接受. 理由是: 縮進的大小是為了清楚的定義一個塊的開始和結束.特別是當你已經在計算機前面呆了20多個小時了以後,你會發現一個大的縮進格式使得你對程序的理解更容易. 現在,有一些人說,使用8個字符的縮進使得代碼離右邊很近,在80個字符寬度的終端屏幕上看程序很難受.回答是,但你的程序有3個以上的縮進的時候,你就應該修改你的程序. 總之,8個字符的縮進使得程序易讀,還有一個附加的好處,就是它能在你將程序變得嵌套層數太多的時候給你警告.這個時候,你應該修改你的程序. 第二章:大符號的位置 另外一個C 程序編程風格的問題是對 大括號的處理. 同縮進大小不同,幾乎沒有什麼理由去選擇一種而不選擇另外一種風格,但有一種推薦的風格,它是 Kernighan 和 Ritchie的經典的那本書帶來的,它將開始的大括號放在一行的最後,而將結束大括號放在一行的第一位,如下所示: if (x is true) { we do y } 然而,還有一種特殊的情況:命名函數: 開始的括號是放在下一行的第一位, 如下: int function(int x) { body of function } 所有非正統的人會非難這種不一致性,但是,所有思維正常的人明白: (第一) K&R是___對___的,(第二)如果K&R不對,請參見第一條. (:-))......另外,函數也是特殊的,不一定非得一致. 需要注意的是結束的括號在它所占的那一行是空的,__除了__它跟隨著同一條語句的繼續符號.如 "while"在 do-while循環中,或者"else"在if語句中.如下: do { body of do-loop } while (condition); 以及 if (x == y) { .. } else if (x > y) { ... } else { .... } 理由: K&R. 另外,注意到這種大括號的放置方法減小了空行的數量,但卻沒有減少可讀性.於是,在屏幕大小受到限制的時候,你就可以有更多的空行來寫些注釋了. 第三章 : 命名系統 C是一種簡潔的語言,那麼,命名也應該是簡潔的. 同MODULE-2以及PASCAL語言不同的是,C程序員不使用諸如 ThisVariableIsATemporaryCounter 之類的命名方式. 一個C語言的程序員會將之命名為"tmp",這很容易書寫,且並不是那麼難以去理解. 然而,當混合類型的名字不得不出現的時候,描述性名字對全局變量來說是必要的了. 調用一個名為"foo"全局的函數是很讓人惱火的. 全局變量( 只有你必須使用的時候才使用它) ,就象全局函數一樣,需要有描述性的命名方式.假如你有一個函數用來計算活動用戶的數量,你應該這樣命名--"count_active_users()"--或另外的相近的形式,你不應命名為"cntusr()". 有一種稱為 Hungarian命名方式,它將函數的類型編碼寫入變量名中,這種方式是腦子有毛病的一種表現 --- 編譯器知道這個類型而且會去檢查它,而這樣只會迷惑程序員. --知道為什麼Micro$oft為什麼會生產這麼多"臭蟲"程序了把!!. 局部變量的命名應該短小精悍. 假如你有一個隨機的整數循環計數器,它有可能有"i",如果沒有任何可能使得它能被誤解的話,將其寫作"loop_counter"是效率低下的.同樣的,""tmp"可以是任何臨時數值的函數變量. 如果你害怕混淆你的局部變量的名字,還有另外一個問題,就是稱 function-growth-hormone-imbalance syndrome. 第四章: 函數 函數應該短小而迷人,而且它只作一件事情. 它應只覆蓋一到兩個屏幕(80*24一屏),並且只作一件事情,而且將它做好.( 這不就是UNIX 的風格嗎,譯者注). 一個函數的最大長度和函數的復雜程度以及縮進大小成反比. 於是, 如果你已經寫了簡單但長度較長的的函數, 而且你已經對不同的情況做了很多很小的事情,寫一個更長一點的函數也是無所謂的. 然而, 假如你要寫一個很復雜的函數, 而且你已經估計到假如一般人讀這個函數,他可能都不知道這個函數在說些什麼,這個時候,使用具有描述性名字的有幫助的函數. 另外一個需要考慮的是局部變量的數量. 他們不應該超過5-10個, 否則你有可能會出錯. 重新考慮這個函數 , 將他們分割成更小的函數. 人的大腦通常可以很容易的記住7件不同的事情,超過這個數量會引起混亂. 你知道你很聰明,但是你可能仍想去明白2周以前的做的事情. 第5章 : 注釋 注釋是一件很好的事情, 但是過多的注釋也是危險的,不要試圖區解釋你的代碼是注釋如何如何的好: 你應該將代碼寫得更好,而不是花費大量的時間去解釋那些糟糕的代碼. 通常情況下,你的注釋是說明你的代碼做些什麼,而不是怎麼做的. 而且,要試圖避免將注釋插在一個函數體裡: 假如這個函數確實很復雜,你需要在其中有部分的注釋,你應該回到第四章看看. 你可以寫些簡短的注釋來注明或警告那些你認為特別聰明(或極其丑陋)的部分, 但是你必須要避免過多. 取而代之的是, 將注釋寫在函數前,告訴別人它做些什麼事情,和可能為什麼要這樣做. 第六章 : 你已經深陷其中了. 不要著急. 你有可能已經被告之"GUN emacs" 會自動的幫你處理C 的源代碼格式, 而且你已經看到它確實如此, 但是, 缺省的情況下, 它的作用還是不盡如人意(實際上,他們比隨便敲出來的東西還要難看 - a infinite number of monkeys typing into GNU emacs would never make a good program) 於是, 你可以要麼 不要使用 GUN emacs, 要麼讓它使用saner valules. 使用後者,你需要將如下的語句輸入到你的 .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)) 這會定義一個 M-x Linux-c-mode 的命令. 當你hacking 一個模塊的時候, 如何你將-*- linux-c -*- 輸入在最開始的兩行, 這個模式會自動起作用. 而且, 你也許想加入如下 (setq auto-mode-alist (cons '("/usr/src/linux.*/.*. 〖ch〗$" . linux-c-mode) auto-mode-alist)) 到你的.emacs文件中, 這樣的話, 當你在/usr/src/linux下編輯文件的時候,它會自動切換到linux-c-mode . 但是, 假如你還不能讓emaces去自動處理文件的格式, 不要緊張, 你還有一樣東西 : "縮進" . GNU 的縮進格式也很死板, 這就是你為什麼需要加上幾行命令選項. 然而, 這還不算太壞,因為GNU 縮進格式的創造者也記得 K&R 的權威, ( GNU 沒有罪, 他們僅僅是在這件事情上錯誤的引導了人們) , 你要做的就只有輸入選項 "-kr -i8"(表示"K&R, 縮進8個字符). "縮進"有很多功能, 特別是當它建議你重新格式你的代碼的時候,你應該看看幫助. 但要記住 : "縮進"不是風格很差的程序的萬靈丹.
