⑴ 有誰知道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文件應有一個同名的.h文件，用於聲明需要對外公開的介面。
禁止頭文件循環依賴。
禁止包含用不到的頭文件。
頭文件應當自包含。
編寫內部#include保護符(#define保護)。
禁止在頭文件中定義變數。
只能通過包含頭文件的方式使用其他C提供的介面，禁止在C中通過extern的方式使用外部函數介面和變數。
禁止在extern "C"中包含頭文件。
函數
函數設計的精髓：編寫整潔函數，同事把代碼有效組織起來。
一個函數僅完成一個功能。
重復代碼應該盡可能提煉成函數。
避免函數過長，新增函數不超過50行。
避免函數的代碼塊嵌套過深，新增函數的代碼塊嵌套不超過4層。
可重入函數應避免使用共享變數；若需要使用，則應該通過互斥手段對其加以保護。
對參數的合法性檢查，由調用者負責還是介面函數負責，應在項目組模塊內統一規定。預設由調用者負責。
對函數的錯誤返回碼要全面處理。
設計高扇入，合理扇出（小於7）的函數。扇出是指調用其它函數的數目。扇入是指有多少上級函數調用它。
廢棄代碼要及時清除。
函數參數不變使用const限定。
函數應避免使用全局變數、靜態局部變數和I/O操作，不可避免的地方應集中使用。
檢查函數所有非參數輸入的有效性，如數據文件、公共變數等。
函數的參數個數不超過5個。
在源文件范圍內聲明和定義的所有函數，除非外部可見，否則應該加static關鍵字。
標識符
標識符的命名要清晰、明了，有明確含義，同時使用完整的單詞或大家基本可以理解的縮寫，避免使人產生誤解。
產品、項目組內應保持同意的命名分格。
盡量避免名字中出現數字編號，除非邏輯上確實需要。
重構、修改部分代碼時，應該保持和原有代碼風格一致。
文件命令統一採用小寫字元。因為不同系統對文件名大小寫處理會有不同（windows不區分大小寫，但是linux系統則區分）。
全局變數應增加「g_」前綴。
靜態變數應增加「s_」前綴。
禁止使用單位元組命名變數，但是允許定義i,j,k作為局部循環變數。
不建議使用匈牙利命名法。
對於數值或者字元串常量的定義，建議採用全大寫字母，單詞之間加下劃線的方式命名。
變數
結構功能單一，不要設計面面俱到的數據結構。
不用或者少用全局變數
防止局部變數與全局變數同名
通訊過程中使用的機構，必須注意位元組序。
嚴禁使用未經初始化的變數作為右值。
使用面向介面編程思想，通過API訪問數據。
盡量減少沒有必要的數據類型默認轉換與強制轉換。
宏和常量
用宏定義表達式時，要使用完備的括弧。
將宏定義的多條表達式放在大括弧中。
使用宏時，不允許參數發生變化。
不允許直接使用魔鬼數字。
除非必要，應盡可能使用函數代替宏。
常量建議用const定義代替宏。
質量
時刻注意易混淆的操作符
必須了解編譯系統的內存分配方式，特別是編譯系統對不同類型的變數的內存分配規則，如局部變數在何處分配、靜態變數在何處分配等。
不僅關注介面，同樣要關注實現。
禁止內存操作越界。
禁止內存泄漏。
禁止引用已經釋放的內存空間。
編程時，要防止差1錯誤。
switch語句必須有default分支。
函數中分配的內存，在函數退出之前要釋放。
不要濫用goto語句。
時刻注意表達式是否會上溢、下溢。
程序效率
在保證軟體系統的正確性、簡潔、可維護性、可靠性及可測試性的前提下，提高代碼的效率。
通過對數據結構、程序演算法的優化來提高效率。
將不變條件的計算移到循環體外。
對於多維大數組，避免來回跳躍式訪問數組成員。
創建資源庫，以減少分配對象的開銷。
將多次被調用的「小函數」改為inline函數或者宏實現。
注釋
優秀的代碼可以自我解釋，不通過注釋即可輕易讀懂。
注釋的內容要清楚、明了，含義准確，防止注釋二義性。
修改代碼時，維護代碼周邊的所有注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。
文件頭部應進行注釋，注釋需要列出：版權說明、版本號、生成日期、作者姓名、工號、內容、功能說明、與其他文件的關系、修改日誌等，頭文件的注釋中還應有函數功能的說明。
函數聲明處注釋描述函數功能、性能及用法，包括輸入和輸出參數、函數返回值、可重入的要求等；定義處詳細描述函數功能和實現要點，如實現的簡要步驟、實現的理由、設計約束等。
全局變數要有詳細的注釋，包括對其功能、取值范圍以及存取時注意事項等的說明。
盡量採用工具可以識別的格式注釋。
排版與格式
程序塊採用縮進風格編寫，每級縮進為4個空格。
相對獨立的程序塊之間、變數說明之後必須加空行。
一行只寫一條語句。
對等操作兩邊加空格，注釋符與內容之間加空格。
編譯
使用編譯器的最高告警級別，理解所有的告警，通過修改代碼而不是降低告警級別來消除所有告警。
在產品軟體中，要統一編譯開關、靜態檢查選項以及相應告警清除策略。
可測性
模塊劃分清晰，介面明確，耦合性小，有明確輸入和輸出，否則單元測試實施困難。
在統一項目組或產品組內，調測列印的日誌要有統一的規定。
使用斷言記錄內部假設。
不能用斷言來檢查運行時錯誤。
⑶ C語言編程
C語言代碼規范（編程規范）
什麼叫規范？在C語言中不遵守編譯器的規定，編譯器在編譯時就會報錯，這個規定叫作規則。但是有一種規定，它是一種人為的、約定成俗的，即使不按照那種規定也不會出錯，這種規定就叫作規范。
雖然我們不按照規范也不會出錯，但是那樣代碼寫得就會很亂。大家剛開始學習C語言的時候，第一步不是說要把程序寫正確，而是要寫規范。因為如果你養成一種非常不好的寫代碼的習慣，代碼就會寫得亂七八糟，等到將來工作面試的時候，這樣的習慣可能會讓你失去機會。
代碼如何寫才能規范
那麼代碼如何寫才能寫得很規范呢？代碼的規范化不是說看完本節內容後就能實現的。它裡面細節很多，而且需要不停地寫代碼練習，不停地領悟，慢慢地才能掌握的一種編程習慣。所以大家不要想著一下子就能把代碼規范化的所有知識全部掌握，也不要想著一下子就能把代碼寫規范，這是不太可能的。
有很多知識，比如為什麼代碼要這樣寫，為什麼不能那樣寫，作為一個初學者你是很難弄明白的。有很多規范是為了在程序代碼量很大的時候，便於自己閱讀，也便於別人閱讀。
所以剛開始的時候有很多規范你不知道為什麼要那樣規定，你就單純地模仿就行了。等將來敲代碼敲得時間長了，你就會感覺到那樣寫是很有好處的。
代碼規范化的好處
代碼規范化的第一個好處就是看著很整齊、很舒服。假如你現在用不規范的方式寫了一萬行代碼，現在能看得懂，但等過了三個月你再回頭看時就很吃力了，更不要說給別人看了。所以代碼要寫規范，比如加註釋就是代碼規范化的一個思想。
在一般情況下，根據軟體工程的思想，我們的注釋要佔整個文檔的20%以上。所以注釋要寫得很詳細，而且格式要寫得很規范。
第二個好處是，把代碼寫規范則程序不容易出錯。如果按照不規范的格式輸入代碼的話，很容易出錯。而代碼寫規范的話即使出錯了查錯也會很方便。格式雖然不會影響程序的功能，但會影響可讀性。程序的格式追求清晰、美觀，是程序風格的重要構成元素。
代碼規范化的七大原則
代碼規范化基本上有七大原則，體現在空行、空格、成對書寫、縮進、對齊、代碼行、注釋七方面的書寫規范上。
1) 空行
空行起著分隔程序段落的作用。空行得體將使程序的布局更加清晰。空行不會浪費內存，雖然列印含有空行的程序會多消耗一些紙張，但是值得。
規則一：定義變數後要空行。盡可能在定義變數的同時初始化該變數，即遵循就近原則。如果變數的引用和定義相隔比較遠，那麼變數的初始化就很容易被忘記。若引用了未被初始化的變數，就會導致程序出錯。
規則二：每個函數定義結束之後都要加空行。
總規則：兩個相對獨立的程序塊、變數說明之後必須要加空行。比如上面幾行代碼完成的是一個功能，下面幾行代碼完成的是另一個功能，那麼它們中間就要加空行。這樣看起來更清晰
⑷ 用c語言實現排列組合問題（華為軟體面試試題之一）
/* 演算法 */
// 從剩餘的nM個籃子里空出nX = m*n - x;個球
int GetBall(int nX, int nM, int n) {
int nA;
int nS = 0;
/* 如果這次情況里確定從一個籃子里空出球 */
// 如果nM等於1 返回 1;
if (nX <= n) {
/* 最少從一個籃子里拿走，最多必須從 nM 與 n 中 較少個數的籃子里拿走 */
// 當nA從 1 增加到 nX，循環執行下行語句
nS += GetBall(nA,1,n) + GetBall(nX-nA,nM-1,n);
// 返回 nS;
} else if (nX > n) {
/* 1. 知道剩下的籃子數目nM，2. 可以保證nX-nA <= nM*n */
// 當nA從 n 減少到 nX-n*nM，循環執行下行語句
nS += GetBall(nA,1,n) + GetBall(nX-nA,nM-1,n);
// 返回 nS;
}
}
int main() {
int m,n,x;
m = 5; n = 6; x = 22;
printf("%d\n",GetBall(m*n-x, m, n));
return 0;
}
⑸ 急求華為語言安全編程規范
華為技術有限公司內部技術規范
DKBA 2826-2011.5
C語言編程規范
鏈接在此，自己下載吧：http://wenku..com/link?url=vaCWEdt8jpMwe6aiB8I3_ZppqHZ0R127xX_-sSmEikJZVUb2XpAteib6KpKNLPAzW-KW
⑹ 華為編程規范
華為編程規范舉例：
1-1：程序塊要採用縮進風格編寫，縮進的空格數為4個。
說明：對於由開發工具自動生成的代碼可以有不一致。
1-2：相對獨立的程序塊之間、變數說明之後必須加空行。
1-3：較長的語句（>80字元）要分成多行書寫，長表達式要在低優先順序操作符處劃分新行，操作符放在新行之首，劃分出的新行要進行適當的縮進，使排版整齊，語句可讀。
1-4：不允許把多個短語句寫在一行中，即一行只寫一條語句。
1-5：if、for、do、while、case、switch、default等語句自佔一行，且if、for、do、while等語句的執行語句部分無論多少都要加括弧{}。
1-6：對齊只使用空格鍵，不使用TAB鍵。
說明：以免用不同的編輯器閱讀程序時，因TAB鍵所設置的空格數目不同而造成程序布局不整齊，不要使用BC作為編輯器合版本，因為BC會自動將8個空格變為一個TAB鍵，因此使用BC合入的版本大多會將縮進變亂。
1-7：函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要採用縮進風格，case語句下的情況處理語句也要遵從語句縮進要求。
1-8：程序塊的分界符（如C/C++語言的大括弧『{』和『}』）應各獨佔一行並且位於同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case 語句中的程序都要採用如上的縮進方式。
1-9：一行程序以小於80字元為宜，不要寫得過長。
2-1：一般情況下，源程序有效注釋量必須在20％以上。
說明：注釋的原則是有助於對程序的閱讀理解，在該加的地方都加了，注釋不宜太多也不能太少，注釋語言必須准確、易懂、簡潔。
2-2：文件頭部應進行注釋，注釋必須列出：版權說明、版本號、生成日期、作者、內容、功能、修改日誌等。
示例：下面這段頭文件的頭注釋比較標准，當然，並不局限於此格式，但上述信息建議要包含在內。
2-3：函數頭部應進行注釋，列出：函數的目的/功能、輸入參數、輸出參數、返回值、調用關系（函數、表）等。
示例：下面這段函數的注釋比較標准，當然，並不局限於此格式，但上述信息建議要包含在內。
2-4：邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性。不再有用的注釋要刪除。
2-5：注釋的內容要清楚、明了，含義准確，防止注釋二義性。
說明：錯誤的注釋不但無益反而有害。
2-6：注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，不可放在下面，如放於上方則需與其上面的代碼用空行隔開。
2-7：對於所有有物理含義的變數、常量，如果其命名不是充分自注釋的，在聲明時都必須加以注釋，說明其物理含義。變數、常量、宏的注釋應放在其上方相鄰位置或右方。
2-8：數據結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋的，必須加以注釋。對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域的注釋放在此域的右方。
2-9：全局變數要有較詳細的注釋，包括對其功能、取值范圍、哪些函數或過程存取它以及存取時注意事項等的說明。
2-10：注釋與所描述內容進行同樣的縮排。
說明：可使程序排版整齊，並方便注釋的閱讀與理解。
2-11：避免在一行代碼或表達式的中間插入注釋。
說明：除非必要，不應在代碼或表達中間插入注釋，否則容易使代碼可理解性變差。
2-12：通過對函數或過程、變數、結構等正確的命名以及合理地組織代碼的結構，使代碼成為自注釋的。
說明：清晰准確的函數、變數等的命名，可增加代碼可讀性，並減少不必要的注釋。
2-13：在代碼的功能、意圖層次上進行注釋，提供有用、額外的信息。
說明：注釋的目的是解釋代碼的目的、功能和採用的方法，提供代碼以外的信息，幫助讀者理解代碼，防止沒必要的重復注釋信息。
⑺ 華為c語言編程規范是怎樣的
鏈接:
《華為編程規范與範例》是一本計算機編程應用類書籍。
⑻ C語言 編程規范
去相關書籍看下
⑼ c語言編碼規范
關於編碼的規范，google為規范開源軟體，開放了程序編碼的文檔。
網頁的鏈接不知能否發上來，如果不能，自己查 Google C++ 風格指南，有中文版。http://yangyubo.com/google-cpp-styleguide/
⑽ C語言的編程規范是什麼
c語言編程是一門特殊的能讓計算機看懂的語言,他也有特殊的語法......