C語言編碼規範1--文件與目錄 https://blog.csdn.net/RootCode/article/details/93221475
C語言編碼規範 2--排版 https://blog.csdn.net/RootCode/article/details/93222263
C語言編碼規範 3 --註釋 https://blog.csdn.net/RootCode/article/details/93223912
C語言編碼規範 4 --可讀性 https://blog.csdn.net/RootCode/article/details/93226117
C語言編碼規範 5--變量、結構、常量、宏 https://blog.csdn.net/RootCode/article/details/93226847
C語言編碼規範 6--函數 https://blog.csdn.net/RootCode/article/details/93227533
（1） 一般情況下，源程序有效註釋量必須在 20％以上。
說明：註釋的原則是有助於對程序的閱讀理解，在該加的地方都加，註釋不宜太多也不能太少，註釋語言必須準確、易懂、簡潔。
（2） 在文件的開始部分，應該給出關於文件版權、內容簡介、修改歷史等項目的說明。
具體的格式請參見如下的說明。在創建代碼和每次更新代碼時，都必須在文件的歷史記錄中標註版本號、日期、作者、更改說明等項目。其中的版本號的格式爲兩個數字字符和一個英文字母字符。數字字符表示大的改變，英文字符表示小的修改。如果有必要，還應該對其它的註釋內容也進行同步的更改。注意：註釋第一行星號要求爲 76 個,結尾行星號爲 1 個。
/****************************************************************************
* Copyright (C), 2010-2011,xxxx-xxxx有限責任公司
* 文件名: main.c
* 內容簡述：
*
* 文件歷史：
* 版本號 日期 作者 說明
* 01a 2010-07-29 王江河 創建該文件
* 01b 2010-08-20 王江河 改爲可以在字符串中發送回車符
* 02a 2010-12-03 王江河 增加文件頭註釋
*/
（3） 對於函數，在函數實現之前，應該給出和函數的實現相關的足夠而精練的註釋信息。內容包括本函數功能介紹，調用的變量、常量說明，形參說明，特別是全局、全程或靜態變量（慎用靜態變量），要求對其初值，調用後的預期值作詳細的闡述。具體的書寫格式和包含的各項內容請參見如下的例子。
示例：
下面這段函數的註釋比較標準，當然，並不侷限於此格式，但上述信息建議要包含在內。
/****************************************************************************
* 函數名 : SendToCard()
* 功 能 : 向讀卡器發命令，如果讀卡器進入休眠，則首先喚醒它
* 輸 入 : 全局變量 gaTxCard[]存放待發的數據
* 全局變量 : gbTxCardLen 存放長度
* 輸 出 : 無
*/
（4） 邊寫代碼邊註釋，修改代碼同時修改相應的註釋，以保證註釋與代碼的一致性。不再有用的註釋要刪除。
（5） 註釋的內容要清楚、明瞭，含義準確，防止註釋二義性。
說明：錯誤的註釋不但無益反而有害。註釋主要闡述代碼做了什麼（What），或者如果有必要的話，闡述爲什麼要這麼做（Why），註釋並不是用來闡述它究竟是如何實現算法（How）的。
（6） 避免在註釋中使用縮寫，特別是非常用縮寫。
說明：在使用縮寫時或之前，應對縮寫進行必要的說明。
（7） 註釋應與其描述的代碼靠近，對代碼的註釋應放在其上方或右方（對單條語句的註釋）相鄰位置，不可放在下面，如放於上方則需與其上面的代碼用空行隔開。
示例：如下例子不符合規範。
例 1：不規範的寫法
/* 獲取複本子系統索引和網絡指示器 */
<---- 不規範的寫法，此處不應該空行
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;
例 2：不規範的寫法
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;
/* 獲取複本子系統索引和網絡指示器 */ <---- 不規範的寫法，應該在語句前註釋
例 3：規範的寫法
/* 獲取複本子系統索引和網絡指示器 */
repssn_ind = ssn_data[index].repssn_index;
repssn_ni = ssn_data[index].ni;
例 4：不規範的寫法，顯得代碼過於緊湊
/* code one comments */
program code one
/* code two comments */ <---- 不規範的寫法，兩段代碼之間需要加空行
program code two
例 5：規範的寫法
/* code one comments */
program code one
/* code two comments */
program code two
（8） 註釋與所描述內容進行同樣的縮排。
說明：可使程序排版整齊，並方便註釋的閱讀與理解。
例 1：如下例子，排版不整齊，閱讀稍感不方便。
void example_fun( void )
{
/* code one comments */ <---- 不規範的寫法，註釋和代碼應該相同的縮進
CodeBlock One
/* code two comments */ <---- 不規範的寫法，註釋和代碼應該相同的縮進
CodeBlock Two
}
例 2：正確的佈局。
void example_fun( void )
{
/* code one comments */
CodeBlock One
/* code two comments */
CodeBlock Two
}
（9） 對變量的定義和分支語句（條件分支、循環語句等）必須編寫註釋。
說明：這些語句往往是程序實現某一特定功能的關鍵，對於維護人員來說，良好的註釋幫助更好的理解程序，有時甚至優於看設計文檔。
（10） 對於 switch 語句下的 case 語句，如果因爲特殊情況需要處理完一個 case 後進入下一個 case 處理，必須在該 case 語句處理完、下一個 case 語句前加上明確的註釋。
說明：這樣比較清楚程序編寫者的意圖，有效防止無故遺漏 break 語句。
示例（注意斜體加粗部分）：
（11） 註釋格式儘量統一，建議使用“/* …… */”，因爲 C++註釋“//”並不被所有 C 編譯器支持。
（12） 註釋應考慮程序易讀及外觀排版的因素，使用的語言若是中、英兼有的，建議多使用中文，除非能非常流利準確的用英文表達。
說明：註釋語言不統一，影響程序易讀性和外觀排版，出於對維護人員的考慮，建議使用中文。
標識符命名
（13） 標識符的命名要清晰、明瞭，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。
說明：較短的單詞可通過去掉“元音”形成縮寫；較長的單詞可取單詞的頭幾個字母形成縮寫；一些單詞有大家公認的縮寫。
示例：如下單詞的縮寫能夠被大家基本認可。
temp 可縮寫爲 tmp;
flag 可縮寫爲 flg;
statistic 可縮寫爲 stat;
increment 可縮寫爲 inc;
message 可縮寫爲 msg;
（14） 命名中若使用特殊約定或縮寫，則要有註釋說明。
說明：應該在源文件的開始之處，對文件中所使用的縮寫或約定，特別是特殊的縮寫，進行必要的註釋說明。
（15） 自己特有的命名風格，要自始至終保持一致，不可來回變化。
說明：個人的命名風格，在符合所在項目組或產品組的命名規則的前提下，纔可使用。（即命名規則中沒有規定到的地方纔可有個人命名風格）。
（16） 對於變量命名，禁止取單個字符（如 i、j、k...），建議除了要有具體含義外，還能表明其變量類型、數據類型等，但 i、j、k 作局部循環變量是允許的。
說明：變量，尤其是局部變量，如果用單個字符表示，很容易敲錯（如i寫成j），而編譯時又檢查不出來，有可能爲了這個小小的錯誤而花費大量的查錯時間。
（17） 命名規範必須與所使用的系統風格保持一致，並在同一項目中統一，比如採用 UNIX 的全小寫加下劃線的風格或大小寫混排的方式，不要使用大小寫與下劃線混排的方式，用作特殊標識如標識成員變量或全局變量的 m_和 g_，其後加上大小寫混排的方式是允許的。
示例： Add_User不允許，add_user、AddUser、m_AddUser允許。
（18） 除非必要，不要用數字或較奇怪的字符來定義標識符。
示例：如下命名，使人產生疑惑。
uint8_t dat01;
void Set00(uint_8 c);
應改爲有意義的單詞命名。
uint8_t ucWidth;
void SetParam(uint_8 _ucValue);
（19） 在同一軟件產品內，應規劃好接口部分標識符（變量、結構、函數及常量）的命名，防止編譯、鏈接時產生衝突。
說明：對接口部分的標識符應該有更嚴格限制，防止衝突。如可規定接口部分的變量與常量之前加上“模塊”標識等。
（20） 除了編譯開關/頭文件等特殊應用，應避免使用_EXAMPLE_TEST_之類以下劃線開始和結尾的定義。