1. 有誰知道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 」)
\
我從公司文檔拷貝的！你自己看看對你有沒有用！
2. 華為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個空格。
相對獨立的程序塊之間、變數說明之後必須加空行。
一行只寫一條語句。
對等操作兩邊加空格，注釋符與內容之間加空格。
編譯
使用編譯器的最高告警級別，理解所有的告警，通過修改代碼而不是降低告警級別來消除所有告警。
在產品軟體中，要統一編譯開關、靜態檢查選項以及相應告警清除策略。
可測性
模塊劃分清晰，介面明確，耦合性小，有明確輸入和輸出，否則單元測試實施困難。
在統一項目組或產品組內，調測列印的日誌要有統一的規定。
使用斷言記錄內部假設。
不能用斷言來檢查運行時錯誤。
3. C語言在編程的時候應注意什麼問題
1.先學習C語言的基礎知識。現在正在學C語言的在校學生可以直接進入第2步學習。
2.按照《C語言程序設計入門學習六步曲》進行上機練習。
3.在上機練習時要養成良好的編程風格。點擊查看C語言的編程風格
4.積極參加C、C++興趣小組，養成和老師與同學交流習慣，從而相互收益。有時別人不經意的一句話可能使你茅塞頓開--「一句話點醒夢中人」。
5.及時總結自己的學習經驗，養成寫C語言日記的習慣。軟體有編程日記功能。
6.從網上或教材上找一個自己感興趣的題目（選題時根據自己的能力，可先易後難，培養自己的成就感，如果有了成就感，即使再苦再累還是感覺C語言學習是一件快樂的事，同學們喜歡打游戲，經常通宵達旦地玩游戲也樂而不疲就是這個道理）進行實戰訓練，提高自己的C語言綜合應用能力。
7. 由於C語言靈活、強大，初學者要全面地掌握它是不可能的，因此在學習C語言的過程中，不要在細枝末節上浪費精力（比如++、--用於表達式的計算，實際上是沒有意義的），但一定要熟練掌握C語言的流程式控制制語句、數組、函數、指針等基礎知識的應用，為學習面向對象程序設計打下堅實的基礎。如果這些知識你學不好，要後續學習好C++、可視化的程序設計Visual C++或C++Builder就像空中樓閣，是不現實的。
C語言程序設計入門學習六步曲
筆者在從事教學的過程中，聽到同學抱怨最多的一句話是：老師，上課我也能聽懂，書上的例題也能看明白，可是到自己動手做編程時，卻不知道如何下手。發生這種現象的原因有三個：
一、所謂的看懂聽明白，只是很膚淺的語法知識，而我們編寫的程序或軟體是要根據要解決問題的實際需要控製程序的流程，如果你沒有深刻地理解C語言的語句的執行過程（或流程），你怎麼會編寫程序解決這些實際問題呢？
二、用C語言編程解決實際問題，所需要的不僅僅是C語言的編程知識，還需要相關的專業知識。例如，如果你不知道長方形的面積公式，即使C語言學得再好你也編不出求長方形的面積的程序來。
三、C語言程序設計是一門實踐性很強的課程，「紙上談兵」式的光學不練是學不好C語言的。例如，大家都看過精彩自行車雜技表演，假如，你從來沒有騎過自行車，光聽教練講解相關的知識、規則、技巧，不要說上台表演、就是上路你恐怕都不行。
出現問題原因清楚了，那麼如何學習呢?請你看【C語言學習六步曲】
在程序開發的過程中，上機調試程序是一個不可缺少的重要環節。「三分編程七分調試」，說明程序調試的工作量要比編程大得多。這里以如何上機調試C程序來說明C語言的學習方法。
第一步、驗證性練習
在這一步要求按照教材上的程序實例進行原樣輸入，運行一下程序是否正確。在這一步基本掌握C語言編程軟體的使用方法（包括新建、打開、保存、關閉C程序，熟練地輸入、編輯C程序；初步記憶新學章節的知識點、養成良好的C語言編程風格）。
初學者最容易犯的錯誤是：
1、沒有區分開教材上的數字1和字母l，字母o和數字0的區別，造成變數未定義的錯誤。另一個易錯點是將英文狀態下的逗號,分號;括弧()雙引號""輸入出入成中文狀態下的逗號，分號；括弧（），雙引號「」造成非法字元錯誤。
2、C語言初學者易犯語法錯誤：使用未定義的變數、標示符（變數、常量、數組、函數等）不區分大小寫、漏掉「；」、「{」與「}」、「（」與「）」不匹、控制語句（選擇、分支、循環）的格式不正確、調用庫函數卻沒有包含相應的頭文件、調用未C聲明的自定義函數、調用函數時實參與形參不匹配、數組的邊界超界等。
3、修改C語言語法錯誤時要注意以下兩點：
（1）、由於C語言語法比較自由、靈活，因此錯誤信息定位不是特別精確。例如，當提示第10行發生錯誤時，如果在第10行沒有發現錯誤，從第10行開始往前查找錯誤並修改之。
（2）、一條語句錯誤可能會產生若干條錯誤信息只要修改了這條錯誤，其他錯誤會隨之消失。特別提示：一般情況下，第一條錯誤信息最能反映錯誤的位置和類型，所以調試程序時務必根據第一條錯誤信息進行修改，修改後，立即運行程序，如果還有很多錯誤，要一個一個地修改，即，每修改一處錯誤要運行一次程序。
第二步、照葫蘆畫瓢
在第一步輸入的C程序的基礎上進行試驗性的修改，運行一下程序看一看程序結果發生了什麼變化，分析結果變化的原因，加深新學知識點的理解。事實上這和第一步時同步進行的，實現「輸入」加深知識的記憶，「修改」加深對知識的理解。記憶和理解是相輔相成的，相互促進。
例如：將最簡單的Hello World!程序
#include "stdio.h"
int main()
{
printf("Hello World!\n");
return 0;
}
中的
printf("Hello World!\n");
中的Hello World!改成你的姓名，運行一下程序，看有什麼變化？
再如求1+2+3...+100的和的程序
#include
main()
{
int i,sum=0;
for(i=1;i<=100;i++)
{
sum=sum+i;
}
printf("sum=%d\n",sum);
}
第1次將for(i=1;i<=100;i++)中的100改成50，運行一下程序，看有什麼變化？
第2次將for(i=1;i<=100;i++)中的i++改成i=i+2，運行一下程序，看有什麼變化？
找出程序結果變化的原因，就加深了對C語句的理解。
第三步、不看教材看是否能將前兩步的程序進行正確地輸入並運行。
在這一步要求不看教材，即使程序不能運行，看能否將其改正，使其能正確運行。目的是對前兩步的記憶、理解進一步強化。
第四步、增強程序的調試能力
在教材中每章都有C語言初學者易犯的錯誤，按照易出錯的類型，將教材中的正確的程序改成錯誤的程序，運行一下程序，看出現的錯誤信息提示，並記下錯誤信息，再將程序改成正確的，運行一下程序。這樣反復修改，就能夠學習C語言程序發生錯誤的原因和修改錯誤的能力。
注意：每次只改錯一個地方，目的是顯示發生該錯誤的真正原因，避免一次改動多個地方，搞清發生錯誤的真正原因，切記！！！！
注意：上機調試程序時要帶一個記錄本，記下英文錯誤提示信息和解決該錯誤問題的方法，積累程序調試經驗，避免在編程犯同樣的錯誤，切記！！！！。
例如，將Hello World程序中語句
printf("Hello World!\n");
中的;改成中文的分號；
運行一下程序，看有什麼結果？
調試程序是一種實踐性很強的事，光紙上談兵是是沒用的，就像游泳運動員只聽教練講解示範，而不親自下水練習，是永遠學不會游泳的。
即使在優秀的程序員編寫程序也會犯錯誤的，可能事最低級的語法錯誤，但他能快速發現錯誤並改正錯誤，而我們C語言初學者面對錯誤提示，不知道發生了什麼錯誤，如何改正，這就事差別。
第五步、研究典型的C語言程序，提高程序設計能力
C語言初學者遇到最多的困惑是：上課也能聽懂，書上的例題也能看明白，可是到自己動手做編程時，卻不知道如何下手。發生這種現象的原因是：所謂的看懂聽明白，只是很膚淺的語法知識，而沒有深刻地理解C語言的語句的執行過程（或流程）。
計算機是按照人的指令（編寫的程序）去執行的，如果不知道這些C語句在計算機中是如何執行的，你怎麼回靈活運用這些知識去解決實際問題呢？
解決問題的方法是要先理解C語言各種語句的流程（即計算機是如何執行這些語句的過程），然後研讀現成C語言經典程序，看懂別人事如何解決問題的，以提高自己的程序設計能力。
第六步、研究課程設計源成序，提高C語言的綜合應用能力.
4. c語言的特點和風格是什麼
c語言面向「結構」編程，操作底層，短小精悍，可算是高級語言編程之母！