摘要：所謂無規(guī)矩不成方圓。任何團隊，規(guī)范都是怎么也繞不開的話題。特別是在我們搞嵌入式C開發(fā)的，代碼規(guī)范乃是開發(fā)的重中之重。有太多的理由去做規(guī)范，因為每個人的代碼編寫喜好不同，代碼風格也迥然不同。每一個程序員心目中對好代碼都有自己的主見，統(tǒng)一的編碼規(guī)范可以像秦始皇統(tǒng)一戰(zhàn)國一樣，避免不必要的論戰(zhàn)和爭議。

有時候會幫同學看一下代碼，發(fā)現(xiàn)大多寫代碼都是隨心所欲?？雌痖_非常頭大，雖然C語言很重要，但是C語言代碼規(guī)范也非常重要。今天分享的就是安富萊C語言編碼規(guī)范，建議初學者去官網(wǎng)看看他們的代碼，非常標準！

一、文件與目錄

1、文件及目錄的命名規(guī)定可用的字符集是A-Z；a-z；0-9；._-。

2、源文件名后綴用小寫字母.c和.h。

3、文件的命名要準確清晰地表達其內(nèi)容，同時文件名應該精練，防止文件名過長而造成使用不便。在文件名中可以適當?shù)厥褂每s寫。

以下提供兩種命名方式以供參考：（1）各程序模塊的文件命名開頭 2 個小寫字母代表本模塊的功能：如：主控程序為mpMain.c，mpDisp.c… （2）不寫模塊功能標識：如：主控程序為Main.c，Disp.c…

4、一個軟件包或一個邏輯組件的所有頭文件和源文件建議放在一個單獨的目錄下，這樣有利于查找并使用相關的文件，有利于簡化一些編譯工具的設置。

5、對于整個項目需要的公共頭文件，應存放在一個單獨的目錄下(例如：myProject/include)下，可避免其他編寫人引用時目錄太過分散的問題。

6、對于源碼文件中的段落安排，我們建議按如下的順序排列：

• a. 文件頭注釋
• b. 防止重復引用頭文件的設置
• c. #include 部分
• d. #define 部分
• e. enum 常量聲明
• f. 類型聲明和定義，包括 struct、union、typedef 等
• g. 全局變量聲明
• h. 文件級變量聲明
• i. 全局或文件級函數(shù)聲明
• j. 函數(shù)實現(xiàn)。按函數(shù)聲明的順序排列
• k. 文件尾注釋

7、在引用頭文件時，不要使用絕對路徑。如果使用絕對路徑，當需要移動目錄時，必須修改所有相關代碼，繁瑣且不安全；使用相對路徑，當需要移動目錄時，只需修改編譯器的某個選項即可。

#include“/project/inc/hello.h”/*不應使用絕對路徑*/
#include“../inc/hello.h”/*可以使用相對路徑*/

8、在引用頭文件時，使用 <> 來引用預定義或者特定目錄的頭文件，使用 “” 來引用當前目錄或者路徑相對于當前目錄的頭文件。

#include/*標準頭文件*/
#include/*工程指定目錄頭文件*/
#include“global.h”/*當前目錄頭文件*/
#include“inc/config.h”/*路徑相對于當前目錄的頭文件*/

9、為了防止頭文件被重復引用，應當用ifndef/define/endif結(jié)構產(chǎn)生預處理塊。

#ifndef__DISP_H/*文件名前名加兩個下劃線“__”，后面加“_H”
#define__DISP_H
...
...
#endif

10、頭文件中只存放“聲明”而不存放“定義”，通過這種方式可以避免重復定義。

/*模塊 1 頭文件：module1.h */
externinta=5;/*在模塊1的.h文件中聲明變量*/

/*模塊 1 實現(xiàn)文件：module1.c */
uint8_tg_ucPara;/*在模塊1的.h文件中定義全局變量g_ucPara*/

11、如果其它模塊需要引用全局變量g_ucPara, 只需要在文件開頭包含module1.h

/*模塊 2 實現(xiàn)文件：module2.c */
#include“module1.h”/*在模塊2中包含模塊1的.h文件*/
......
g_ucPara=0;
......

12、對于文件的長度沒有非常嚴格的要求，但應盡量避免文件過長。一般來說，文件長度應盡量保持在1000行之內(nèi)。

二、排版

1、程序塊要采用縮進風格編寫，縮進的空格數(shù)為 4 個。

2、相對獨立的程序塊之間、變量說明之后必須加空行。

voidDemoFunc(void)

{

uint8_ti;

<----?局部變量和語句間空一行

/*功能塊1*/

for(i=0;i10;i++)

{

...

}

<----?不同的功能塊間空一行

/*功能塊2*/

for(i=0;i20;i++)

{

...

}

}

3、作符處劃分新行，操作符放在新行之首，劃分出的新行要進行適當?shù)目s進，使排版整齊，語句可讀。

if((ucParam1==0)&&(ucParam2==0)&&(ucParam3==0)

||(ucParam4==0))<----?長表達式需要換行書寫

{

......

}

4、不允許把多個短語句寫在一行中，即一行只寫一條語句。

rect.length=0;rect.width=0;<----?不正確的寫法

rect.length?=?0;<----?正確的寫法

rect.width?=?0;

5、對齊使用TAB 鍵，1 個 TAB 對應 4 個字符位。

6、函數(shù)或過程的開始、結(jié)構的定義及循環(huán)、判斷等語句中的代碼都要采用縮進風格，case 語句下的情況處理語句也要遵從語句縮進要求。

7、程序塊的分界符（如大括號‘{’和‘}’ ）應各獨占一行并且位于同一列，同時與引用它們的語句左對齊。在函數(shù)體的開始、類的定義、結(jié)構的定義、枚舉的定義以及 if、for、do、while、switch、case 語句中的程序都要采用如上的縮進方式。對于與規(guī)則不一致的現(xiàn)存代碼，應優(yōu)先保證同一模塊中的風格一致性。

for(...){<----?不規(guī)范的寫法

...?/*programcode*/

}

for(...)

{<----?規(guī)范的寫法

...?/*programcode*/

}

if(...)

{<----?不規(guī)范的寫法

...?/*programcode*/

}

if(...)

{<----?規(guī)范的寫法

...?/*programcode*/

}

8、在兩個以上的關鍵字、變量、常量進行對等操作時，它們之間的操作符之前、之后或者前后要加空格；進行非對等操作時，如果是關系密切的立即操作符(如－>)，后不應加空格。說明：采用這種松散方式編寫代碼的目的是使代碼更加清晰。

由于留空格所產(chǎn)生的清晰性是相對的，所以，在已經(jīng)非常清晰的語句中沒有必要再留空格，如果語句已足夠清晰則括號內(nèi)側(cè)(即左括號后面和右括號前面)不需要加空格，多重括號間不必加空格，因為在 C語言中括號已經(jīng)是最清晰的標志了。

在長語句中，如果需要加的空格非常多，那么應該保持整體清晰，而在局部不加空格。給操作符留空格時不要連續(xù)留兩個以上空格。

（1）逗號、分號只在后面加空格。

int_32a,b,c;

（2）比較操作符，賦值操作符"="、 "+="，算術操作符"+"、"%"，邏輯操作符"&&"、"&"，位域操作符"<<"、"^"等雙目操作符的前后加空格。

if(current_time>=MAX_TIME_VALUE)
a=b+c;
a*=2;
a=b^2;

（3）"!"、"~"、"++"、"--"、"&"（地址運算符）等單目操作符前后不加空格。

*p='a';/*內(nèi)容操作"*"與內(nèi)容之間*/
flag=!isEmpty;/*非操作"!"與內(nèi)容之間*/
p=&mem;/*地址操作"&"與內(nèi)容之間*/
i++;/*"++","--"與內(nèi)容之間*/

（4）"->"、"."前后不加空格。

p->id=pid;/*"->"指針前后不加空格*/

（5）if、for、while、switch 等與后面的括號間應加空格，使 if 等關鍵字更為突出、明顯，函數(shù)名與其后的括號之間不加空格，以與保留字區(qū)別開。

if(a>=b&&c>d)

三、注釋

1、一般情況下，源程序有效注釋量必須在 20％以上。說明：注釋的原則是有助于對程序的閱讀理解，在該加的地方都加，注釋不宜太多也不能太少，注釋語言必須準確、易懂、簡潔。

2、在文件的開始部分，應該給出關于文件版權、內(nèi)容簡介、修改歷史等項目的說明。具體的格式請參見如下的說明。在創(chuàng)建代碼和每次更新代碼時，都必須在文件的歷史記錄中標注版本號、日期、作者、更改說明等項目。其中的版本號的格式為兩個數(shù)字字符和一個英文字母字符。數(shù)字字符表示大的改變，英文字符表示小的修改。如果有必要，還應該對其它的注釋內(nèi)容也進行同步的更改。注意：注釋第一行星號要求為 76 個,結(jié)尾行星號為 1 個。

/****************************************************************************

*Copyright(C),2010-2011,武漢xxx系統(tǒng)有限責任公司

*文件名:main.c

*內(nèi)容簡述：

*

*文件歷史：

*版本號日期作者說明

*01a2020-07-29xxx創(chuàng)建該文件

*01b2020-08-20xxx改為可以在字符串中發(fā)送回車符

*02a2020-12-03xxx增加文件頭注釋

*/

3、對于函數(shù)，在函數(shù)實現(xiàn)之前，應該給出和函數(shù)的實現(xiàn)相關的足夠而精練的注釋信息。內(nèi)容包括本函數(shù)功能介紹，調(diào)用的變量、常量說明，形參說明，特別是全局、全程或靜態(tài)變量（慎用靜態(tài)變量），要求對其初值，調(diào)用后的預期值作詳細的闡述。具體的書寫格式和包含的各項內(nèi)容請參見如下的例子。

下面這段函數(shù)的注釋比較標準，當然，并不局限于此格式，但上述信息建議要包含在內(nèi)。

/****************************************************************************

*函數(shù)名:SendToCard()

*功能:向讀卡器發(fā)命令，如果讀卡器進入休眠，則首先喚醒它

*輸入:全局變量gaTxCard[]存放待發(fā)的數(shù)據(jù)

*全局變量gbTxCardLen存放長度

*輸出:無

*/

4、邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。

5、注釋的內(nèi)容要清楚、明了，含義準確，防止注釋二義性。說明：錯誤的注釋不但無益反而有害。注釋主要闡述代碼做了什么（What），或者如果有必要的話，闡述為什么要這么做（Why），注釋并不是用來闡述它究竟是如何實現(xiàn)算法（How）的。

6、避免在注釋中使用縮寫，特別是非常用縮寫。說明：在使用縮寫時或之前，應對縮寫進行必要的說明。

7、注釋應與其描述的代碼靠近，對代碼的注釋應放在其上方或右方(對單條語句的注釋)相鄰位置，不可放在下面，如放于上方則需與其上面的代碼用空行隔開。

例 1：不規(guī)范的寫法

/*獲取復本子系統(tǒng)索引和網(wǎng)絡指示器*/

<----?不規(guī)范的寫法，此處不應該空行

repssn_ind?=?ssn_data[index].repssn_index;

repssn_ni?=?ssn_data[index].ni;

例 2：不規(guī)范的寫法

repssn_ind=ssn_data[index].repssn_index;

repssn_ni=ssn_data[index].ni;

/*獲取復本子系統(tǒng)索引和網(wǎng)絡指示器*/<----?不規(guī)范的寫法，應該在語句前注釋

例 3：規(guī)范的寫法

/*獲取復本子系統(tǒng)索引和網(wǎng)絡指示器*/

repssn_ind=ssn_data[index].repssn_index;

repssn_ni=ssn_data[index].ni;

例 4：不規(guī)范的寫法，顯得代碼過于緊湊

/*codeonecomments*/

programcodeone

/*codetwocomments*/<----?不規(guī)范的寫法，兩段代碼之間需要加空行

program?code?two

例 5：規(guī)范的寫法

/*codeonecomments*/

programcodeone

/*codetwocomments*/

programcodetwo

8、注釋與所描述內(nèi)容進行同樣的縮排。說明：可使程序排版整齊，并方便注釋的閱讀與理解。

例 1：如下例子，排版不整齊，閱讀稍感不方便。

voidexample_fun(void)

{

/*codeonecomments*/<----?不規(guī)范的寫法，注釋和代碼應該相同的縮進

CodeBlock?One

/*codetwocomments*/<----?不規(guī)范的寫法，注釋和代碼應該相同的縮進

CodeBlock?Two

}

例 2：正確的布局。

voidexample_fun(void)

{

/*codeonecomments*/

CodeBlockOne

/*codetwocomments*/

CodeBlockTwo

}

9、對變量的定義和分支語句（條件分支、循環(huán)語句等）必須編寫注釋。說明：這些語句往往是程序?qū)崿F(xiàn)某一特定功能的關鍵，對于維護人員來說，良好的注釋幫助更好的理解程序，有時甚至優(yōu)于看設計文檔。

10、對于switch語句下的case語句，如果因為特殊情況需要處理完一個case后進入下一個case 處理，必須在該case語句處理完、下一個case語句前加上明確的注釋。說明：這樣比較清楚程序編寫者的意圖，有效防止無故遺漏 break 語句。

11、注釋格式盡量統(tǒng)一，建議使用“/* …… */”，因為 C++注釋“//”并不被所有 C 編譯器支持。

12、注釋應考慮程序易讀及外觀排版的因素，使用的語言若是中、英兼有的，建議多使用中文，除非能非常流利準確的用英文表達。說明：注釋語言不統(tǒng)一，影響程序易讀性和外觀排版，出于對維護人員的考慮，建議使用中文。

13、標識符的命名要清晰、明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產(chǎn)生誤解。

說明：較短的單詞可通過去掉“元音”形成縮寫；較長的單詞可取單詞的頭幾個字母形成縮寫；一些單詞有大家公認的縮寫。示例：如下單詞的縮寫能夠被大家基本認可。

temp可縮寫為tmp;
flag可縮寫為flg;
statistic可縮寫為stat;
increment可縮寫為inc;
message可縮寫為msg;

14、命名中若使用特殊約定或縮寫，則要有注釋說明。說明：應該在源文件的開始之處，對文件中所使用的縮寫或約定，特別是特殊的縮寫，進行必要的注釋說明。

15、自己特有的命名風格，要自始至終保持一致，不可來回變化。說明：個人的命名風格，在符合所在項目組或產(chǎn)品組的命名規(guī)則的前提下，才可使用。(即命名規(guī)則中沒有規(guī)定到的地方才可有個人命名風格)。

16、對于變量命名，禁止取單個字符（如 i、j、k...），建議除了要有具體含義外，還能表明其變量類型、數(shù)據(jù)類型等，但 i、j、k 作局部循環(huán)變量是允許的。說明：變量，尤其是局部變量，如果用單個字符表示，很容易敲錯（如i寫成j），而編譯時又檢查不出來，有可能為了這個小小的錯誤而花費大量的查錯時間。

17、命名規(guī)范必須與所使用的系統(tǒng)風格保持一致，并在同一項目中統(tǒng)一，比如采用 UNIX 的全小寫加下劃線的風格或大小寫混排的方式，不要使用大小寫與下劃線混排的方式，用作特殊標識如標識成員變量或全局變量的 m_和 g_，其后加上大小寫混排的方式是允許的。

示例：Add_User不允許，add_user、AddUser、m_AddUser允許。

18、 除非必要，不要用數(shù)字或較奇怪的字符來定義標識符。示例：如下命名，使人產(chǎn)生疑惑。

uint8_tdat01;

voidSet00(uint_8c);

應改為有意義的單詞命名。

uint8_tucWidth;

voidSetParam(uint_8_ucValue);

19、在同一軟件產(chǎn)品內(nèi)，應規(guī)劃好接口部分標識符（變量、結(jié)構、函數(shù)及常量）的命名，防止編譯、鏈接時產(chǎn)生沖突。說明：對接口部分的標識符應該有更嚴格限制，防止沖突。如可規(guī)定接口部分的變量與常量之前加上“模塊”標識等。

20、除了編譯開關/頭文件等特殊應用，應避免使用_EXAMPLE_TEST_之類以下劃線開始和結(jié)尾的定義。

四、變量、結(jié)構、常量、宏

1、為了方便書寫及記憶，變量類型采用如下重定義：

typedefunsignedcharuint8_t;

typedefunsignedshortuint16_t;

typedefunsignedlongintuint32_t;

typedefsignedcharint8_t;

typedefsignedshortint16_t;

typedefsignedlongintint32_t;

#define__IOvolatile

2、常見類型的前綴

（1）對于一些常見類型的變量，應在其名字前標注表示其類型的前綴。前綴用小寫字母表示。前綴的使用請參照下列表格中說明。（2）對于幾種變量類型組合，前綴可以迭加。

3、變量作用域的前綴

為了清晰的標識變量的作用域，減少發(fā)生命名沖突，應該在變量類型前綴之前再加上表示變量作用域的前綴，并在變量類型前綴和變量作用域前綴之間用下劃線-隔開。

（1）對于全局變量（global variable），在其名稱前加g和變量類型符號前綴。

uint32_tg_ulParaWord;

uint8_tg_ucByte;

（2）對于靜態(tài)變量（static variable），在其名稱前加“s”和變量類型符號前綴。

staticuint32_ts_ulParaWord;

staticuint8_ts_ucByte;

（3）函數(shù)內(nèi)部等局部變量前不加作用域前綴。（4）對于常量，當可能發(fā)生作用域和名字沖突問題時，以上幾條規(guī)則對于常量同樣適用。注意，雖然常量名的核心部分全部大寫，但此時常量的前綴仍然用小寫字母，以保持前綴的一致性。

4、對于結(jié)構體命名類型，表示類型的名字，所有名字以小寫字母tag開頭，之后每個英文單詞的第一個字母大寫(包括第一個單詞的第一個字母)，其他字母小寫，結(jié)尾_T標識。單詞之間不使用下劃線分隔,結(jié)構體變量以t開頭。

/*結(jié)構體命名類型名*/

typedefstructtagBillQuery_T

{

...

}BillQuery_T;

/*結(jié)構體變量定義*/

BillQuery_TtBillQuery;

對于枚舉定義全部采用大寫，結(jié)尾_E標識。

typedefenum

{

KB_F1=0,/*F1鍵代碼*/

KB_F2,/*F2鍵代碼*/

KB_F3/*F3鍵代碼*/

}KEY_CODE_E;

5、常量、宏、模版的名字應該全部大寫。如果這些名字由多個單詞組成，則單詞之間用下劃線分隔。宏指所有用宏形式定義的名字，包括常量類和函數(shù)類；常量也包括枚舉中的常量成員。

#defineLOG_BUF_SIZE8000

6、不推薦使用位域。

五、函數(shù)

1、函數(shù)的命名規(guī)則。每一個函數(shù)名前綴需包含模塊名，模塊名為小寫，與函數(shù)名區(qū)別開。如：uartReceive(串口接收)備注：對于非常簡單的程序，可以不加模塊名。

2、函數(shù)的的形參需另啟一行，在后面給予說明，形參都以下劃線_開頭，已示與普通變量進行區(qū)分，對于沒有形參為空的函數(shù)(void)括號緊跟函數(shù)后面。

/******************************************************************************

*函數(shù)名：uartConvUartBaud

*功能：波特率轉(zhuǎn)換

*輸入：_ulBaud :波特率

*輸出：無

*返回：uint32-轉(zhuǎn)換后的波特率值

*/

uint32_tuartConvUartBaud(uint32_t_ulBaud)

{

uint32_tulBaud;

ulBaud=ulBaud*2;/*計算波特率*/

......

returnulBaud;

}

復制代碼

3、一個函數(shù)僅完成一件功能。

4、函數(shù)名應準確描述函數(shù)的功能。避免使用無意義或含義不清的動詞為函數(shù)命名。使用動賓詞組為執(zhí)行某操作的函數(shù)命名。說明：避免用含義不清的動詞如process、handle等為函數(shù)命名，因為這些動詞并沒有說明要具體做什么。示例：參照如下方式命名函數(shù)。

voidPrintRecord(uint32_t_RecInd);

int32InputRecord(void);

uint8_tGetCurrentColor(void);

5、檢查函數(shù)所有參數(shù)輸入的有效性。說明：如果約定由調(diào)用方檢查參數(shù)輸入，則應使用assert()之類的宏，來驗證所有參數(shù)輸入的有效性。

6、檢查函數(shù)所有非參數(shù)輸入的有效性，如數(shù)據(jù)文件、公共變量等。說明：函數(shù)的輸入主要有兩種：一種是參數(shù)輸入；另一種是全局變量、數(shù)據(jù)文件的輸入，即非參數(shù)輸入。函數(shù)在使用輸入之前，應進行必要的檢查。

7、防止將函數(shù)的參數(shù)作為工作變量。說明：將函數(shù)的參數(shù)作為工作變量，有可能錯誤地改變參數(shù)內(nèi)容，所以很危險。對必須改變的參數(shù)，最好先用局部變量代之，最后再將該局部變量的內(nèi)容賦給該參數(shù)。

8、避免設計五個以上參數(shù)函數(shù)，不使用的參數(shù)從接口中去掉。說明：目的減少函數(shù)間接口的復雜度，復雜的參數(shù)可以使用結(jié)構傳遞。

9、在調(diào)用函數(shù)填寫參數(shù)時，應盡量減少沒有必要的默認數(shù)據(jù)類型轉(zhuǎn)換或強制數(shù)據(jù)類型轉(zhuǎn)換。說明：因為數(shù)據(jù)類型轉(zhuǎn)換或多或少存在危險。

10、避免使用 BOOL 參數(shù)。說明：原因有二，其一是BOOL參數(shù)值無意義，TURE/FALSE的含義是非常模糊的，在調(diào)用時很難知道該參數(shù)到底傳達的是什么意思；其二是BOOL參數(shù)值不利于擴充。還有NULL也是一個無意義的單詞。

11、函數(shù)的返回值要清楚、明了。除非必要，最好不要把與函數(shù)返回值類型不同的變量，以編譯系統(tǒng)默認的轉(zhuǎn)換方式或強制的轉(zhuǎn)換方式作為返回值返回。

12、防止把沒有關聯(lián)的語句放到一個函數(shù)中。說明：防止函數(shù)或過程內(nèi)出現(xiàn)隨機內(nèi)聚。隨機內(nèi)聚是指將沒有關聯(lián)或關聯(lián)很弱的語句放到同一個函數(shù)或過程中。隨機內(nèi)聚給函數(shù)或過程的維護、測試及以后的升級等造成了不便，同時也使函數(shù)或過程的功能不明確。使用隨機內(nèi)聚函數(shù)，常常容易出現(xiàn)在一種應用場合需要改進此函數(shù)，而另一種應用場合又不允許這種改進，從而陷入困境。

在編程時，經(jīng)常遇到在不同函數(shù)中使用相同的代碼，許多開發(fā)人員都愿把這些代碼提出來，并構成一個新函數(shù)。若這些代碼關聯(lián)較大并且是完成一個功能的，那么這種構造是合理的，否則這種構造將產(chǎn)生隨機內(nèi)聚的函數(shù)。示例：如下函數(shù)就是一種隨機內(nèi)聚。

voidInitVar(void)

{

Rect.length=0;

Rect.width=0;/*初始化矩形的長與寬*/

Point.x=10;

Point.y=10;/*初始化“點”的坐標*/

}

矩形的長、寬與點的坐標基本沒有任何關系，故以上函數(shù)是隨機內(nèi)聚。應如下分為兩個函數(shù)：

voidInitRect(void)

{

Rect.length=0;

Rect.width=0;/*初始化矩形的長與寬*/

}

voidInitPoint(void)

{

Point.x=10;

Point.y=10;/*初始化“點”的坐標*/

}

13、減少函數(shù)本身或函數(shù)間的遞歸調(diào)用。

說明：遞歸調(diào)用特別是函數(shù)間的遞歸調(diào)用（如A->B->C->A），影響程序的可理解性；遞歸調(diào)用一般都占用較多的系統(tǒng)資源（如棧空間）；遞歸調(diào)用對程序的測試有一定影響。故除非為某些算法或功能的實現(xiàn)方便，應減少沒必要的遞歸調(diào)用。

14、改進模塊中函數(shù)的結(jié)構，降低函數(shù)間的耦合度，并提高函數(shù)的獨立性以及代碼可讀性、效率和可維護性。優(yōu)化函數(shù)結(jié)構時，要遵守以下原則：

1. 能影響模塊功能的實現(xiàn)。
2. 仔細考查模塊或函數(shù)出錯處理及模塊的性能要求并進行完善。
3. 通過分解或合并函數(shù)來改進軟件結(jié)構。
4. 考查函數(shù)的規(guī)模，過大的要進行分解。
5. 降低函數(shù)間接口的復雜度。
6. 不同層次的函數(shù)調(diào)用要有較合理的扇入、扇出。
7. 函數(shù)功能應可預測。
8. 提高函數(shù)內(nèi)聚。（單一功能的函數(shù)內(nèi)聚最高）

說明：對初步劃分后的函數(shù)結(jié)構應進行改進、優(yōu)化，使之更為合理。

審核編輯 ：李倩