『壹』 有沒有自動規范c語言代碼書寫格式並自動對齊排版的軟體
windows 下visual stdio 或者visual c++中可以安裝assit x 或者選擇 按alt+f8
linux 下有eclipse
其他的還沒見過什麼好方法
『貳』 C語言編程
C語言代碼規范（編程規范）
什麼叫規范？在C語言中不遵守編譯器的規定，編譯器在編譯時就會報錯，這個規定叫作規則。但是有一種規定，它是一種人為的、約定成俗的，即使不按照那種規定也不會出錯，這種規定就叫作規范。
雖然我們不按照規范也不會出錯，但是那樣代碼寫得就會很亂。大家剛開始學習C語言的時候，第一步不是說要把程序寫正確，而是要寫規范。因為如果你養成一種非常不好的寫代碼的習慣，代碼就會寫得亂七八糟，等到將來工作面試的時候，這樣的習慣可能會讓你失去機會。
代碼如何寫才能規范
那麼代碼如何寫才能寫得很規范呢？代碼的規范化不是說看完本節內容後就能實現的。它裡面細節很多，而且需要不停地寫代碼練習，不停地領悟，慢慢地才能掌握的一種編程習慣。所以大家不要想著一下子就能把代碼規范化的所有知識全部掌握，也不要想著一下子就能把代碼寫規范，這是不太可能的。
有很多知識，比如為什麼代碼要這樣寫，為什麼不能那樣寫，作為一個初學者你是很難弄明白的。有很多規范是為了在程序代碼量很大的時候，便於自己閱讀，也便於別人閱讀。
所以剛開始的時候有很多規范你不知道為什麼要那樣規定，你就單純地模仿就行了。等將來敲代碼敲得時間長了，你就會感覺到那樣寫是很有好處的。
代碼規范化的好處
代碼規范化的第一個好處就是看著很整齊、很舒服。假如你現在用不規范的方式寫了一萬行代碼，現在能看得懂，但等過了三個月你再回頭看時就很吃力了，更不要說給別人看了。所以代碼要寫規范，比如加註釋就是代碼規范化的一個思想。
在一般情況下，根據軟體工程的思想，我們的注釋要佔整個文檔的20%以上。所以注釋要寫得很詳細，而且格式要寫得很規范。
第二個好處是，把代碼寫規范則程序不容易出錯。如果按照不規范的格式輸入代碼的話，很容易出錯。而代碼寫規范的話即使出錯了查錯也會很方便。格式雖然不會影響程序的功能，但會影響可讀性。程序的格式追求清晰、美觀，是程序風格的重要構成元素。
代碼規范化的七大原則
代碼規范化基本上有七大原則，體現在空行、空格、成對書寫、縮進、對齊、代碼行、注釋七方面的書寫規范上。
1) 空行
空行起著分隔程序段落的作用。空行得體將使程序的布局更加清晰。空行不會浪費內存，雖然列印含有空行的程序會多消耗一些紙張，但是值得。
規則一：定義變數後要空行。盡可能在定義變數的同時初始化該變數，即遵循就近原則。如果變數的引用和定義相隔比較遠，那麼變數的初始化就很容易被忘記。若引用了未被初始化的變數，就會導致程序出錯。
規則二：每個函數定義結束之後都要加空行。
總規則：兩個相對獨立的程序塊、變數說明之後必須要加空行。比如上面幾行代碼完成的是一個功能，下面幾行代碼完成的是另一個功能，那麼它們中間就要加空行。這樣看起來更清晰
『叄』 C語言代碼規范問題
第二種就可以了，幹嘛中間空格
『肆』 C語言中代碼規范問題：表達式的大括弧的左大括弧寫在哪比較規范如下有兩種，大家給給意見。
這是兩種不同的風格，並沒有更規范一說
有的大牛認為第一種比較好 有的大牛認為第二種比較好 爭來爭去，這個不會有最終結論的。
你習慣那種就使用那種就可以了，如果你是和別人一個團隊進行開發，隨著團隊的風格來就可以了。
『伍』 C語言 代碼 怎麼寫的規范 把下面的 寫的規范
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int a, i = 10;
printf("猜數字游戲，（10到200之間）您只有10次機會猜中哦，請輸入\n");
scanf("%d", &a);
while (a!=88 && i>0)
{
if (a>88)
{
printf("你輸入的數字過高\n");
}
else
{
printf("你輸入的數字過低\n");
}
scanf("%d", &a);
i--;
}
if(a == 88)
{
printf("恭喜你!猜對了!\n");
}
else
{
printf("你的10次機會已經用完了\n");
}
system("pause");
return 0;
}
『陸』 有誰知道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語言里有printf函數來實現輸出字元等功能。
這些C語言函數還是挺多的，不同的C語言規范中庫函數有所不同，不過大同小異。另外等你有一定基礎後可以自己編寫一些好的函數來作為庫函數，以後實現這種特定功能時可以調用這一函數。
明白了吧？
『玖』 c語言，代碼的規范性，舉例說下，
首先定義一個鏈表。
struct
node
{
int
id;
struct
node
*
next;
};
接下來寫一些操作的函數（插入，刪除等等）。
插入函數：
struct
node*
insert(struct
node*
pNode,
int
iTemp)
{
//判斷
pNode
是否為空。
if(pNode==NULL)
{
//這個節點是空，返回錯誤。
return
NULL;
}
//
創建一個新的節點。
struct
node*
tempNode
=
(struct
node*)malloc(sizeof(struct
node));
tempNode->id=
iTemp;
if(pNode->next
==
NULL)
{
pNode->next
=
tempNode;
tempNode->next
=
NULL;
}else
{
struct
node
*
pNext
=
pNode->next;
pNode->next
=
tempNode;
tempNode->next
=
pNext;
}
return
tempNode;
}
int
main()
{
struct
node*
head
=
(struct
node*)malloc(sizeof(struct
node));
head->id
=
0;
head->next
=
NULL;
struct
node
*
ptemp;
ptemp
=
head;
for(
int
i=1;
i<10;
i++)
{
struct
node*
temp
=
insert(ptemp,i);
ptemp
=
temp;
}
return
0;
}