Linux內(nèi)核編碼風格(編程代碼風格推薦)

1、這是翻譯版本，英文原版是linux源碼Documentation文件夾下的CodingStyle一個良好風格的程序看起來直觀、美觀，便于閱讀，還能有助于對程序的理解，特別在代碼量比較大情況下更顯現(xiàn)編碼素質(zhì)的重要性。相反沒有良好的風格的代碼讀起來難看、晦澀，甚至有時候一個括號沒對齊就能造成對程序的曲解或者不理解。我曾經(jīng)就遇見過這樣的情況，花費了很多不必要的時間在程序的上下文對照上，還debug了半天沒理解的程序。后來直接用indent-kr-i8給他轉(zhuǎn)換格式來看了。特此轉(zhuǎn)過來一個關(guān)于代碼風格的帖子分享一下Linux 內(nèi)核編碼風格這是一份簡短的，描述linux內(nèi)核首選編碼風格的文檔。編碼風格是很個

2、人化的東西，而且我也不愿意把我的觀點強加給任何人，不過這里所講述的是我必須要維護的代碼所遵守的風格，并且我也希望絕大多數(shù)其他代碼也能遵守這個風格。所以請至少考慮一下本文所述的觀點首先，我建議你打印一份GNU的編碼規(guī)范，然后不要讀它。燒掉它，這是一個很高調(diào)的具有象征意義的姿態(tài)。Anyway,heregoes:第一章：縮進制表符是8個字符，所以縮進也是8個字符。有些異端運動試圖將縮進變?yōu)?（乃至2）個字符深，這跟嘗試著將圓周率PI的值定義為3沒什么兩樣。理由：縮進的全部意義就在于清楚的定義一個控制塊起止于何處。尤其是當你盯著你的屏幕連續(xù)看了20小時之后，你將會發(fā)現(xiàn)大一點的縮進將會使你更容易分辨縮進

3、。現(xiàn)在，有些人會抱怨8個字符的縮進會使代碼向右邊移動的太遠，在80個字符的終端屏幕上就很難讀這樣的代碼。這個問題的答案是，如果你需要3級以上的縮進，不管縮進深度如何你的代碼已經(jīng)有問題了，應該修正你的程序。簡而言之，8個字符的縮進可以讓代碼更容易閱讀，還有一個好處是當你的函數(shù)嵌套太深的時候可以向你提出告警。請留意這個警告。在switch語句中消除多級縮進的首選的方式是讓switch和從屬于它的caseB簽對齊于同一列，而不要兩次縮進”“case簽。比如：switch(suffix)caseG:caseg:mem=30;break;caseM:casem:mem=20;break;caseK:ca

4、sek:memfor、while、do)。比如:switch(action)caseKOBJ_ADD:returnadd;caseKOBJ_REMOVE:returnremove;caseKOBJ_CHANGE:returnchange;default:returnNULL;)不過，有一種特殊情況，命名函數(shù)：它們的起始大括號放置于下一行的開頭，這樣：intfunction(intx)bodyoffunction)全世界的異端可能會抱怨這個不一致性，呃確實是不一致的，不過所有思維健全的人都知道(a)K&R是正確的，并且(b)K&R是正確的。另外，不管怎樣函數(shù)都是特殊的(在C語言中

5、，函數(shù)是不能嵌套的)。注意結(jié)束大括號獨自占據(jù)一行，除非它后面跟著同一個語句的剩余部分，比如說do語句中的while或者if語句中的“else,”像這樣：dobodyofdo-loopwhile(condition);if(x=y)elseif(xy)else理由：K&R。也請注意這種大括號的放置方式還能使空(或者差不多空的)行的數(shù)量最小化，同時不失可讀性。因此，由于你的屏幕上的新行的供應不是可回收的資源(想想25行的終端屏幕)，你將會有更多的空行來放置注釋。僅有一個單獨的語句時，不用加不必要的大括號。和縮進大小不同，選擇或棄用某種放置策Kernighan和Ritchie展示給我們的，,

6、所以：if(condition)action();這點不適用于本身為某個條件語句的一個分支的單獨語句。這時應該兩個分支里都使用大括號。if(condition)do_this();do_that();elseotherwise();3.1:空格Linux內(nèi)核的空格使用方格(主要)取決于它是用于函數(shù)還是關(guān)鍵字。(大多數(shù))關(guān)鍵字后要加一個空格。值得注意的例外是sizeof、typeof、alignof和_attribute_,這些關(guān)鍵字在一定程度上看起來更像函數(shù)(它們在Linux里也常常伴隨小括號使用，盡管在C語言里這樣的小括號不是必需的，就像structfileinfoinfo聲明過后的size

7、ofinfo)”所以在這些關(guān)鍵字之后放一個空格：if,switch,case,for,do,while但是不在sizeof、typeof、alignof或者_attribute_這些關(guān)鍵字之后放空格。 例如，s=sizeof(structfile);不要在小括號里的表達式兩側(cè)加空格。這是一個反例：s=sizeof(structfile);當聲明指針類型或者返回指針類型的函數(shù)時，“*的首選使用方式是使之靠近變量名或者函數(shù)名，而不是靠近類型名。例子：char*linux_banner;unsignedlonglongmemparse(char*ptr,char*retptr);char*match

8、_strdup(substring_t*s);在大多數(shù)二元和三元操作符兩側(cè)使用一個空格，例如下面所有這些操作符：=+-*/%|&A=!=?:但是一元操作符后不要加空格：&*+!sizeoftypeofalignof_attribute_defined后綴自增和自減一元操作符前不加空格：+-前綴自增和自減一元操作符后不加空格：+-“和-”結(jié)構(gòu)體成員操作符前后不加空格。不要在行尾留空白。有些可以自動縮進的編輯器會在新行的行首加入適量的空白，然后你就可以直接在那一行輸入代碼。不過假如你最后沒有在那一行輸入代碼，有些編輯器就不會移除已經(jīng)加入的空白，就像你故意留下一個只有空白的行。包含行

9、尾空白的行就這樣產(chǎn)生了。當Git發(fā)現(xiàn)補丁包含了行尾空白的時候會警告你，并且可以應你的要求去掉行尾空白；不過如果你是正在打一系列補丁，這樣做會導致后面的補丁失敗，因為你改變了補丁的上下文。第四章：命名C是一個簡樸的語言，你的命名也應該這樣。和Modula-2和Pascal程序員不同，C程序員不使用類似ThisVariablelsATemporaryCounter這樣華麗的名字。C程序員會稱那個變量為“tmp,”這樣寫起來會更容易，而且至少不會令其難于理解。不過，雖然混用大小寫的名字是不提倡使用的，但是全局變量還是需要一個具描述性的名字。稱一個全局函數(shù)為“foo是一個難以饒恕的錯誤。全局變量(只有

10、當你真正需要它們的時候再用它)需要有一個具描述性的名字，就像全局函數(shù)。如果你有一個可以計算活動用戶數(shù)量的函數(shù)，你應該叫它count_a(tive_users()”或者類似的名字，你不應該叫它cntuser()?！痹诤瘮?shù)名中包含函數(shù)類型(所謂的匈牙利命名法)是腦子出了問題一一編譯器知道那些類型而且能夠檢查那些類型，這樣做只能把程序員弄糊涂了。難怪微軟總是制造出有問題的程序。本地變量名應該簡短， 而且能夠表達相關(guān)的含義。 如果你有一些隨機的整數(shù)型的循環(huán)計數(shù)器， 它應該被稱為“i。 ”叫它loop_counter并無益處，如果它沒有可能被誤解的話。類似的“tmp”可以用來稱呼任意類型的臨時變量。如果

11、你怕混淆了你的本地變量名，你就遇到另一個問題了，叫做函數(shù)增長荷爾蒙失衡綜合癥。請看第六章（函數(shù)）。第五章：Typedef不要使用類似“vps_t之類的東西。對結(jié)構(gòu)體和指針使用typedef是一個錯誤。當你在代碼里看到：vps_ta;這代表什么意思呢？相反，如果是這樣structvirtual_container*a;你就知道“娉什么了。很多人認為typedef能提高可讀性實際不是這樣的。它們只在下列情況下有用：（a）完全不透明的對象（這種情況下要主動使用typedef來隱藏這個對象實際上是什么）。例如：pte_tl?不透明對象，你只能用合適的訪問函數(shù)來訪問它們。注意！不透明性和訪問函數(shù)本身”是

12、不好的。我們使用pte_t等類型的原因在于真的是完全沒有任何共用的可訪問信息。（b）清楚的整數(shù)類型，這樣抽象層就可以幫助我們消除到底是int還是long的混淆。u8/u16/u32是完全沒有問題的typedef,不過它們更符合（d）中所言，而不是這里。再次注意！要這樣做，必須事出有因。如果某個變量是aunsignedlong,那么沒有必要typedefunsignedlongmyflags_t;不過如果有一個明確的原因，比如它在某種情況下可能會是一個unsignedint而”在其他情況下可能為unsignedlong,那么就不要猶豫，請務必使用typedef。(c)當你使用sparse按字面的

13、創(chuàng)建一個新類型來做類型檢查的時候(d)和標準C99類型相同的類型，在某些例外的情況下。雖然讓眼睛和腦筋來適應新的標準類型比如“uint32_t不需要花很多時間，可以有些人仍然拒絕使用它們。因此，Linux特有的等同于標準類型的u8/u16/u32/u64類型和它們的有符號類型是被允許的一一盡管在你自己的新代碼中，它們不是強制要求要使用的。當編輯已經(jīng)使用了某個類型集的已有代碼時，你應該遵循那些代碼中已經(jīng)做出的選擇。(e)可以在用戶空間安全使用的類型。在某些用戶空間可見的結(jié)構(gòu)體里，我們不能要求C99類型而且不能用上面提到的“u32”類型。因此，我們在與用戶空間共享的所有結(jié)構(gòu)體中使用_u32和類似的

14、類型。可能還有其他的情況，不過基本的規(guī)則是永遠不要使用typedef,除非你可以明確的應用上述某個規(guī)則中的一個。總的來說，如果一個指針或者一個結(jié)構(gòu)體里的元素可以合理的被直接訪問到，那么它們就不應該是一個typedef。第六章：函數(shù)函數(shù)應該簡短而漂亮，并且只完成一件事情。函數(shù)應該可以一屏或者兩屏顯示完(我們都知道ISO/ANSI屏幕大小是80 x24),只做一件事情，而且把它做好。一個函數(shù)的最大長度是和該函數(shù)的復雜度和縮進級數(shù)成反比的。所以，如果你有一個理論上很簡單的只有一個很長(但是簡單)的case語句的函數(shù)，而且你需要在每個case里做很多很小的事情，這樣的函數(shù)盡管很長，但也是可以的。不過，

15、如果你有一個復雜的函數(shù)，而且你懷疑一個天分不是很高的高中一年級學生可能甚至搞不清楚這個函數(shù)的目的，你應該更嚴格的遵守最大限制。使用輔助函數(shù)，并為之取個具描述性的名字(如果你覺得其對性能要求嚴格的話，你可以要求編譯器將它們內(nèi)聯(lián)展開，它往往會比你更好的完成任務。)函數(shù)的另外一個衡量標準是本地變量的數(shù)量。此數(shù)量不應超過5-10個，否則你的函數(shù)就有問題了。重新考慮一下你的函數(shù)，把它分拆成更小的函數(shù)。人的大腦一般可以輕松的同時跟蹤7個不同的事物，如果再增多的話，就會糊涂了。即便你聰穎過人，你也可能會記不清你2個星期前做過的事情。在源文件里，使用空行隔開不同的函數(shù)。如果該函數(shù)需要被導出，它的EXPORT*

16、宏應該緊貼在它的結(jié)束大括號之下。比如：intsystem_is_up(void)(returnsystem_state=SYSTEM_RUNNING;EXPORT_SYMBOL(system_is_up);在函數(shù)原型中，包含函數(shù)名和它們的數(shù)據(jù)類型。雖然C語言里沒有這樣的要求，在Linux里這是提倡的做法，因為這樣可以很簡單的給讀者提供更多的有價值的信息。第七章：集中的函數(shù)退由途徑雖然被某些人聲稱已經(jīng)過時，但是goto語句的等價物還是經(jīng)常被編譯器所使用，具體形式是無條件跳轉(zhuǎn)指令。當一個函數(shù)從多個位置退出并且需要做一些通用的清潔工作的時候，goto的好處就顯現(xiàn)出來了。理由是：- 無條件語句容易理解

17、和跟蹤- 嵌套程度減小- 可以避免由于修改時忘記更新某個單獨的退出點而導致的錯誤- 減輕了編譯器的工作，無需刪除冗余代碼;)intfun(inta)(intresult=0;char*buffer=kmalloc(SIZE);if(buffer=NULL)return-ENOMEM;if(condition1)while(loop1)result=1;gotoout;out:kfree(buffer);returnresult;第八章：注釋注釋是好的，不過有過度注釋的危險。永遠不要在注釋里解釋你的代碼是如何運作的：更好的做法是讓別人一看你的代碼就可以明白，解釋寫的很差的代碼是浪費時間。一般的，

18、你想要你的注釋告訴別人你的代碼做了什么，而不是怎么做的。也請你不要把注釋放在一個函數(shù)體內(nèi)部：如果函數(shù)復雜到你需要獨立的注釋其中的一部分，你很可能需要回到第六章看一看。你可以做一些小注釋來注明或警告某些很聰明（或者槽糕）的做法，但不要加太多。你應該做的，是把注釋放在函數(shù)的頭部，告訴人們它做了什么，也可以加上它做這些事情的原因。當注釋內(nèi)核API函數(shù)時，請使用kernel-doc格式。請看Documentation/kernel-doc-nano-HOWTO.txt和scripts/kernel-doc以獲得詳細信息。Linux的注釋風格是C89/*.*/風格不要使用C99風格“.注釋長（多行）的首

19、選注釋風格是：/* Thisisthepreferredstyleformulti-line* commentsintheLinuxkernelsourcecode.* Pleaseuseitconsistently.* Description:Acolumnofasterisksontheleftside,*withbeginningandendingalmost-blanklines.* /注釋數(shù)據(jù)也是很重要的，不管是基本類型還是衍生類型。為了方便實現(xiàn)這一點，每一行應只聲明一個數(shù)據(jù)（不要使用逗號來一次聲明多個數(shù)據(jù)）。這樣你就有空間來為每個數(shù)據(jù)寫一段小注釋來解釋它們的用途了。第九章：你已經(jīng)把

20、事情弄糟了這沒什么，我們都是這樣。可能你的使用了很長時間Unix的朋友已經(jīng)告訴你“GNUemacs能自動幫你格式化C源代碼，而且你也注意到了，確實是這樣，不過它所使用的默認值和我們想要的相去甚遠（實際上，甚至比隨機打的還要差一一無數(shù)個猴子在GNUemacs里打字永遠不會創(chuàng)造出一個好程序）（譯注：請參考InfiniteMonkeyTheorem）所以你要么放棄GNUemacs,要么改變它讓它使用更合理的設(shè)定。要采用后一個方案，你可以把下面這段粘貼到你的.emacs文件里。(defunlinux-c-mode()CmodewithadjusteddefaultsforusewiththeLinux

21、kernel.(interactive)(c-mode)(c-set-styleK&R)(setqtab-width8)(setqindent-tabs-modet)(setqc-basic-offset8)這樣就定義了M-xlinux-c-mode命令。當你hack一個模塊的時候，如果你把字符串-*-linux-c-*-放在頭兩行的某個位置，這個模式將會被自動調(diào)用。如果你希望在你修改/usr/src/linux里的文件時魔術(shù)般自動打開linux-c-mode的話，你也可能需要添力口(setqauto-mode-alist(cons(/usr/src/linux.*/.*.ch$”.l

22、inux-c-mode)auto-mode-alist)到你的.emacs文件里。不過就算你嘗試讓emacs正確的格式化代碼失敗了，也并不意味著你失去了一切：還可以用不過，GNUindent也有和GNUemacs一樣有問題的設(shè)定，所以你需要給它一些命令選項。不過，這還不算太糟糕，因為就算是GNUindent的作者也認同K&R的權(quán)威性(GNU的人并不是壞人，他們只是在這個問題上被嚴重的誤導了)，所以你只要給indent指定選項-kr-i8”(代表“K&R8個字符縮進”)，或者使用“scripts/Lindent,這樣就可以以最時髦的方式縮進源代碼。indent有很多選項，特別是重

23、新格式化注釋的時候，你可能需要看一下它的手冊頁。不過記住：“indent不能修正壞的編程習慣。第十章：Kconfig 配置文件對于遍布源碼樹的所有Kcon的*配置文件來說，它們縮進方式與C代碼相比有所不同。緊挨在“config定義下面的行縮進一個制表符，幫助信息則再多縮進2個空格。比如：configAUDITboolAuditingsupportdependsonNEThelpEnableauditinginfrastructurethatcanbeusedwithanotherkernelsubsystem,suchasSELinux(whichrequiresthisforloggingo

24、favcmessagesoutput).Doesnotdosystem-callauditingwithoutCONFIG_AUDITSYSCALL.仍然被認為不夠穩(wěn)定的功能應該被定義為依賴于“EXPERIMENTAL:configSLUBdependsonEXPERIMENTAL&!ARCH_USES_SLAB_PAGE_STRUCTboolSLUB(UnqueuedAllocator).而那些危險的功能(比如某些文件系統(tǒng)的寫支持)應該在它們的提示字符串里顯著的聲明這一點：configADFS_FS_RWboolADFSwritesupport(DANGEROUS)dependson

25、ADFS_FS.要查看配置文件的完整文檔，請看Documentation/kbuild/kcon巾g-language.txt。第十一章：數(shù)據(jù)結(jié)構(gòu)如果一個數(shù)據(jù)結(jié)構(gòu)，在創(chuàng)建和銷毀它的單線執(zhí)行環(huán)境之外可見，那么它必須要有一個引用計數(shù)器。內(nèi)核里沒有垃圾收集(并且內(nèi)核之外的垃圾收集慢且效率低下)，這意味著你絕對需要記錄你對這種數(shù)據(jù)結(jié)構(gòu)的使用情況。引用計數(shù)意味著你能夠避免上鎖，并且允許多個用戶并行訪問這個數(shù)據(jù)結(jié)構(gòu)一一而不需要擔心這個數(shù)據(jù)結(jié)構(gòu)僅僅因為暫時不被使用就消失了，那些用戶可能不過是沉睡了一陣或者做了一些其他事情而已。注意上鎖不能取代引用計數(shù)。上鎖是為了保持數(shù)據(jù)結(jié)構(gòu)的一致性，而引用計數(shù)是一個內(nèi)存管理

26、技巧。通常二者都需要，不要把兩個搞混了。很多數(shù)據(jù)結(jié)構(gòu)實際上有2級引用計數(shù)，它們通常有不同類”的用戶。子類計數(shù)器統(tǒng)計子類用戶的數(shù)量，每當子類計數(shù)器減至零時，全局計數(shù)器減一。這種多級引用計數(shù)”的例子可以在內(nèi)存管理(structmm_struct:mm_users和mm_count)和文件系統(tǒng)(“structsuper_block:s_count和s_active)中找至U。記?。喝绻硪粋€執(zhí)行線索可以找到你的數(shù)據(jù)結(jié)構(gòu)，但是這個數(shù)據(jù)結(jié)構(gòu)沒有引用計數(shù)器，這里幾乎肯定是一個bug。第十二章：宏，列舉(enum)和 RTL定義常量和列舉里的標簽的宏的名字需要大寫。#defineCONSTANT0 x123

27、45在定義幾個相關(guān)的常量時，最好用列舉。宏的名字請用大寫字母，不過形如函數(shù)的宏的名字可以用小寫字母。一般的，如果能寫成內(nèi)聯(lián)函數(shù)就不要寫成像函數(shù)的宏。含有多個語句的宏應該被包含在一個#definemacrofun(a,b,c)doif(a=5)do_this(b,c);while(0)使用宏的時候應避免的事情：1)影響控制流程的宏：#defineFOO(x)doif(blah(x)0)return-EBUGGERED;while(0)非常不好。它看起來像一個函數(shù)，不過卻能導致dontbreaktheinternalparsersofthosewhowillreadthecode.2)依賴于一個固

28、定名字的本地變量的宏：#defineFOO(val)bar(index,val)可能看起來像是個不錯的東西，不過它非常容易把讀代碼的人搞糊涂，而且容易導致看起來不相關(guān)的改動帶來錯誤。3)作為左值的帶參數(shù)的宏：FOO(x)=y;如果有人把FOO變成一個內(nèi)聯(lián)函數(shù)的話，這種用法就會出錯了。do-while代碼塊里:調(diào)用”它的函數(shù)退出;4)忘記了優(yōu)先級：使用表達式定義常量的宏必須將表達式置于一對小括號之內(nèi)。帶參數(shù)的宏也要注意此類問題。#defineCONSTANT0 x4000#defineCONSTEXP(CONSTANT|3)cpp手冊對宏的講解很詳細。Gccinternals手冊也詳細講解了RT

29、L(譯注：registertransferlanguage),內(nèi)核里的匯編語言經(jīng)常用到它。第十三章：打印內(nèi)核消息內(nèi)核開發(fā)者應該是受過良好教育的。請一定注意內(nèi)核信息的拼寫，以給人以好的印象。不要用不規(guī)范的單詞比如“dont,而要用donot或者dont。”保證這些信息簡單、明了、無歧義。內(nèi)核信息不必以句點結(jié)束。在小括號里打印數(shù)字(d)沒有任何價值，應該避免這樣做。里有一些驅(qū)動模型診斷宏，你應該使用它們，以確保信息對應于正確的設(shè)備和驅(qū)動，并且被標記了正確的消息級別。這些宏有：dev_err(),dev_warn(),dev_info()等等。對于那些不和某個特定設(shè)備相關(guān)連的信息，定義了pr_deb

30、ug()和pr_info()。寫出好的調(diào)試信息可以是一個很大的挑戰(zhàn)；當你寫出來之后，這些信息在遠程除錯的時候就會成為極大的幫助。當DEBUG符號沒有被定義的時候，這些信息不應該被編譯進內(nèi)核里(也就是說，默認地，它們不應該被包含在內(nèi))。如果你使用dev_dbg()或者pr_debug(),就能自動達到這個效果。很多子系統(tǒng)擁有Kconfig選項來啟用-DDEBUG。還有一個相關(guān)的慣例是使用VERBOSE_DEBUG來添加dev_vdbg()消息到那些已經(jīng)由DEBUG啟用的消息之上。第十四章：分配內(nèi)存內(nèi)核提供了下面的一般用途的內(nèi)存分配函數(shù)：kmalloc(),kzalloc(),kcalloc()和

31、vmalloc()。請參考API文檔以獲取有關(guān)它們的詳細信息。傳遞結(jié)構(gòu)體大小的首選形式是這樣的：p=kmalloc(sizeof(*p),.);另外一種傳遞方式中，sizeof的操作數(shù)是結(jié)構(gòu)體的名字，這樣會降低可讀性，并且可能會引入bug。有可能指針變量類型被改變時，而對應的傳遞給內(nèi)存分配函數(shù)的sizeof的結(jié)果不變。強制轉(zhuǎn)換一個void指針返回值是多余的。C語言本身保證了從void指針到其他任何指針類型的轉(zhuǎn)換是沒有問題的。第十五章：內(nèi)聯(lián)弊病有一個常見的誤解是內(nèi)聯(lián)函數(shù)是gcc提供的可以讓代碼運行更快的一個選項。雖然使用內(nèi)聯(lián)函數(shù)有時候是恰當?shù)模ū热缱鳛橐环N替代宏的方式，請看第十二章），不過很多情

32、況下不是這樣。inline關(guān)鍵字的過度使用會使內(nèi)核變大，從而使整個系統(tǒng)運行速度變慢。因為大內(nèi)核會占用更多的指令高速緩存（譯注：一級緩存通常是指令緩存和數(shù)據(jù)緩存分開的）而且會導致pagecache的可用內(nèi)存減少。想象一下，一次pagecache未命中就會導致一次磁盤尋址，將耗時5毫秒。5毫秒的時間內(nèi)CPU能執(zhí)行很多很多指令。一個基本的原則是如果一個函數(shù)有3行以上，就不要把它變成內(nèi)聯(lián)函數(shù)。這個原則的一個例外是，如果你知道某個參數(shù)是一個編譯時常量，而且因為這個常量你確定編譯器在編譯時能優(yōu)化掉你的函數(shù)的大部分代碼，那仍然可以給它加上inline關(guān)鍵字。kmalloc（）內(nèi)聯(lián)函數(shù)就是一個很好的例子。人們經(jīng)常主張給static的而且只用了一次的函數(shù)加上inline,不會有任何損失，因為這種情況下沒有什么好權(quán)衡的。雖然從技術(shù)上說，這是正確的，不過gcc可以在沒有提示的情況下自動使其內(nèi)聯(lián)，而且其他用戶可能會要求移除inline,此種維護上的爭論會抵消可以告訴gcc來做某些事情的提示帶來的潛在價值。不管有沒有inline,這種函數(shù)都會被內(nèi)聯(lián)。第十六章：函數(shù)返回值及命名函數(shù)可以返回很多種不同類型的值，最常見的一種是表明函數(shù)執(zhí)行成功或者失敗的