A. C語言編程規范問題
只看得出第一個應該是錯誤的，重命名後的uint8_t的含義跟前面的unsigned char是相等的，無符號字元，重復了。
B. 有誰知道C語言程序的編程規范，給我概括一下，
1引言
1.1編寫目的
在軟體開發過程中，編碼的工作量是相當大的，同一項目參與編程的人可能有各自編程的經驗和習慣，不同風格的程序代碼使維護工作變得復雜和困難。為了提高代碼的可讀性、系統的穩定性及降低維護和升級的成本，特編寫本規范以統一各開發人員的編程工作。
1.2 適用對象
本規范適用於所有開發人員，包括應用程序、網頁及資料庫開發人員，及有關的程序測試人員。
1.3 引用標准
GB/T 11457 軟體工程術語
GB 8566 計算機軟體開發規范
GB 8567 計算機軟體產品開發文件編制指南
2．編寫要求
2.1一般代碼規則
可讀性原則，這是評價程序質量的首選指標，寧可不要一些技巧也要保證程序的易讀特性，不要因過分追求技巧而犧牲程序的可讀性。
功能獨立性原則。每一程序塊只完成一個獨立的功能，反過來，每一獨立的功能只在一程序塊內完成，盡量低耦合、高內聚。
提示說明應當簡短且避免產生歧義。
提示或警告信息應當具有向導性，能准確告訴用戶錯誤原因及恢復方法。提示和警告對話框應當使用標准規范。
快捷鍵的定義必須符合用戶操作習慣。
程序需要長時間處理或等待時，應當顯示進度條並提示用戶等待。
一些敏感操作，如刪除等操作在執行前必須提示用戶確認。
2.2變數、函數、過程、控制項等命名規則
2.2.1 變數命名
變數命名採用[作用范圍][數據類型][自定義名稱]規則定義，並遵循匈牙利命名法。要求看到變數名就能直觀的看出其范圍和數據類型。
匈牙利命名規則：
a Array 數組
b BOOL (int) 布爾(整數)
by Unsigned Char (Byte) 無符號字元(位元組)
c Char 字元(位元組)
cb Count of bytes 位元組數
cr Color reference value 顏色(參考)值
cx Count of x (Short) x的集合(短整數)
dw DWORD (unsigned long) 雙字(無符號長整數)
f Flags (usually multiple bit values) 標志(一般是有多位的數值)
fn Function 函數
g_ global 全局的
h Handle 句柄
i Integer 整數
l Long 長整數
lp Long pointer 長指針
m_ Data member of a class 一個類的數據成員
n Short int 短整數
p Pointer 指針
s String 字元串
sz Zero terminated String 以0結尾的字元串
tm Text metric 文本規則
u Unsigned int 無符號整數
ul Unsigned long (ULONG) 無符號長整數
w WORD (unsigned short) 無符號短整數
x,y x, y coordinates (short) 坐標值/短整數
v void 空
作用范圍：
范圍 前綴 例子
全局作用域 g_ g_Servers
成員變數 m_ m_pDoc
局部作用域 無 strName
數據類型
VC常用前綴列表
前綴 類型 描述 例子
ch char 8位字元 chGrade
ch TCHAR 16位UNICODE類型字元 chName
b BOOL 布爾變數 bEnabled
n int 整型（其大小由操作系統決定） nLength
n UINT 無符號整型（其大小由操作系統決定） nLength
w WORD 16位無符號整型 wPos
l LONG 32位有符號整型 lOffset
dw DWORD 32位無符號整型 dwRange
p * 內存模塊指針，指針變數 pDoc
l p FAR* 長指針 lpDoc
lpsz LPSTR 32位字元串指針 lpszName
lpsz LPCSTR 32位常量字元串指針 lpszName
lpsz LPCTSTR 32位UNICODE類型常量指針 lpszName
h handle Windows對象句柄 hWnd
lpfn (*fn)() 回調函數指針 Callback Far pointer to
CALLBACK function lpfnAbort
2.2.2 函數、過程命名
函數或過程名的主體應該使用大小寫混合形式，並且應該足夠長以描述它的作用。而且，函數名應該以一個動詞起首，如 InitNameArray 或 CloseDialog。對於頻繁使用的或長的項，推薦使用標准縮略語以使名稱的長度合理化。一般來說，超過 32 個字元的變數名在 VGA 顯示器上讀起來就困難了。當使用縮略語時，要確保它們在整個應用程序中的一致性。在一個工程中，如果一會兒使用 Cnt， 一會兒使用 Count，將導致不必要的混淆。
對於自行編寫的函數，若是系統關鍵函數，則須在函數實現部分的上方標明該函數的信息，格式如下：
//======================================================
// 函 數 名：InsureHasOutputInfo
// 功能描述：確保有適當的輸出信息
// 輸入參數：nProctID:相應的產品ID
// 輸出參數：void
// 創建日期：00-2-21
// 修改日期：00-2-21
// 作 者：***
// 附加說明：
//======================================================
2.2.3 用戶定義類型
在一項有許多用戶定義類型的大工程中，常常有必要給每種類型一個它自己的三個字元的前綴。如果這些前綴是以 "u" 開始的，那麼當用一個用戶定義類型來工作時，快速識別這些類型是很容易的。例如，ucli 可以被用來作為一個用戶定義的客戶類型變數的前綴。
註：對於非通用的變數，請在定義時加以注釋說明，變數定義盡可能放在最開始處。
2.2.4 控制項命名
應該用一致的前綴來命名對象，使人們容易識別對象的類型。
VC常用宏定義命名列表
前綴 符號類型 符號例子 范圍
IDR_ 標識多個資源共享的類型 IDR_MAINFRAME 1~0x6FFF
IDD_ 對話框資源（Dialog） IDD_SPELL_CHECK 1~ 0x6FFF
HIDD_ 基於對話框的上下文幫助 HIDD_SPELL_CHECK 0x20001~0x26FF
IDB_ 點陣圖資源（Bitmap） IDB_COMPANY_LOGO 1~0x6FFF
IDC_ 游標資源（Cursor） IDC_PENCIL 1~0x6FFF
IDI_ 圖標資源（Icon） IDI_NOTEPAD 1~0x6FFF
ID_、IDM_ 工具欄或菜單欄的命令項 ID_TOOLS_SPELLING 0x8000~0xDFFF
HID_ 命令上下文幫助 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 消息框提示文字資源 IDP_INVALID_PARTNO 8~0xDFFF
HIDP_ 消息框上下文幫助 HIDP_INVALID_PARTNO 0x30008~0x3DFFF
IDS_ 字元串資源（String） IDS_COPYRIGHT 1~0x7FFF
IDC_ 對話框內的控制資源 IDC_RECALC 8~0xDFFF
2.3源代碼規則
2.3.1風格約定：採用縮進的格式保存程序的層次結構。要求能直觀的看出循環、判斷等層次結構。
每一個嵌套的函數塊，使用一個TAB縮進（可以設定為4個空格），大括弧必須放在條件語句的下一行，單獨成一行，便於匹對反大括弧應該在單獨的一行，在大多數情況下反擴號應有注釋內容。舉例如下：
if(condition1)
{
while(condition2)
{
…..
…..
}//end while(condition2)
}//end if (condition1)
或者
if(condition1){
while(condition2){
….
….
}//end while(condition2)
}//end if(conditionl)
2.3.2在操作符的前後必須使用空格。
2.3.3在分隔數組下標和函數參數的逗號後面必須添上空格。
2.3.4嚴禁使用go to 語句。
2.3.5對資料庫操作只能使用標准SQL語句，關鍵字必須使用大寫（如SELECT、WHERE等），數據元素（表、欄位、視圖等）必須按照數據字典書寫。
2.3.6程序代碼中要有足夠的容錯處理功能。
對可能發生的異常統一採用C++拋出格式：
try
{
//可能引發異常的代碼
throw t; //手工拋出異常
}
catch(type_1 e) // type_1為類型定義符、如int、CException、_com_error
{
// type_1類型異常處理
}
catch(type_2 e)
{
// type_2類型異常處理
}
2.3.7程序代碼結構必須層次清楚，適當使用空行分段。
2.3.8工程的版本控制要嚴格，版本格式為.me.ae.yy.mmdd，其中：[me]表示主版本號；[ae]表示輔版本號；[yy.mmdd]表示版本建立日期。高版本盡量兼容低版本的用法、數據或協議。
2．4文件的命名規則
2.4.1根據系統設計所規定的結構，建立相應的文件夾，根據需要建立子文件夾。
2.4.2文件夾和文件的名稱應盡量能夠表達其意義，盡量使用英文命名，絕對不能漢字。
2.4.3文件名稱一般採用「xxx_yyy.ext」格式，xxx(3-4個字母)表示分類，yyy(字母數自定)表示操作 (如 「 /example/exp_edit.htm 」)
\
我從公司文檔拷貝的！你自己看看對你有沒有用！
C. c語言書寫的規則
= , ; + - / 他們左右的空格還是不空格，空幾個格都看你的習慣的。沒有關系
int 這類的定義後邊至少有一個空格，多了不限
D. 谷歌發布的C 編程規范
http://wenku..com/view/f5f2fe87bceb19e8b8f6ba23.html
E. C編程規范怎麼樣
這本書相當適合有一定C++編程經驗的初級，中級程序員閱讀。這本書討論了101個規則，每個規則都按照，固定的格式（包括條款標題，摘要，討論，示例等部分）進行說明。這樣的編排方式即清晰又符合我們理解接受的漸進過程。 也許可以邊看書邊試著做一些回憶，想想自己是否在編程時候使用或注意到這些規范。還可以問自己一些問題，例如在我們的設計風格中是否注意了，」對一個函數之賦予一種職責「，」正確，簡單和清晰第一，軟體簡單為美（Keep It Simple Software, KISS）「，」優先使用線性演算法或者盡可能快的演算法：例如O(N)「，」盡量減少全局和共享數據（會增加耦合度，從而降低可維護性，通常還會降低性能）「等等。 我們也可以考慮一下我們的編程風格，並問自己: 我們有沒有做到避免使用宏， 盡可能局部聲明變數, 總是初始化變數，避免函數過長，避免嵌套過深，是否做到確保所編寫的每個頭文件都能夠獨自進行編譯。 C++之父Bjarne Stroustrup說過「軟體開發最重要的一個方面就是弄清楚自己要構建的是什麼」，對於類的設計與繼承這一部分也相當值得一讀，例如以下條款「用小類代替巨類」，「 用組合代替繼承」，「避免從並非要設計成基類的類中繼承」，「優先提供抽象介面」，「共用繼承即可替換性。繼承，不是為了重用，而是為了被重用，Liskov替換原則: Liskov Substitution Principle，共用繼承所建模的必須總是「是一個is a」，更精確的「其行為象一個 works like a 」關系：所有基類約定必須滿足這一點。」等等，也許我們對這些規則都瞭然於胸，但是我們是否時時刻刻注意到這些規則呢，這本書就提供了這樣一個「小聲音」，提醒我們，在經過一段時間的編程後，我們也許常常會被一些「壞習慣」占據，這個「小聲音」，也許就是摒除這些「壞習慣」的利器， 也許你和我一樣在編寫C++的時候會不自覺地使用了一些不先進的C的方式，例如使用數組，匈牙利標法，switch等等，看了這本書後絕對會大有啟發，例如以下的部分書摘： 」匈牙利記法：將類型信息並入變數名的記法，是混用了類型不安全語言（特別是C）中的設施，這在面向對象語言中是可以存在的，但是有害無益，在泛型編程則更不不行。所以，任何C++編程規范都不應該要求使用匈牙利記法，而在規范中選擇禁用該記法則是合理的。「 」通過類型分支（type switching）來定製行為既不牢固，容易出錯，又不安全，而且是企圖用C++編寫C代碼的明顯標志。這是一種很不靈活的技術，要添加新特性時必須回過頭對現有代碼進行修改。它還不安全，因為添加新類型時，如果忘記修改所有分支，編譯器也不會告知。「 「不要使用C語言風格的數組，指針運算和內存管理原語操作實現數組抽象。使用vector或者string不僅更輕松，而且還有助於編寫更安全，伸縮性更好的軟體。毋庸置疑，在當今軟體中緩沖區溢出和安全缺陷是罪魁禍首。固定長度的數組所帶來的愚蠢限制，即使仍在正確界限內，也是軟體開發人員的一大困擾。」 」不要使用C風格的強制轉換。「 初級，中級程序員看了本書後一定會大有收獲，掌握這些規范，也許是成長為優秀程序員的重要的堅實一步。 ------- ------ 本文原始地址：http://hanyionet.blogspot.com/2009/09/blog-post_20.html
F. 華為c語言編程規范是怎樣的
鏈接:
《華為編程規范與範例》是一本計算機編程應用類書籍。
G. 最新c語言編程規范是什麼
已發送到你的郵箱，請查收。註：郵件伺服器可能有延遲，郵件發出後半分鍾內即可收到；若仍沒收到，請首先檢查您郵箱的垃圾箱！
H. C語言編程規范
把調用函數寫在前面。
如果需調用的函數在後面，需在main函數前聲明
一半習慣把自定義函數寫在前面
I. C語言的編程規范是什麼
c語言編程是一門特殊的能讓計算機看懂的語言,他也有特殊的語法......