A. c/c++代碼風格如何選擇
匈牙利命名法
匈牙利命名法是一種編程時的命名規范。基本原則是：變數名＝屬性＋類型＋對象描述，其中每一對象的名稱都要求有明確含義，可以取對象名字全稱或名字的一部分。命名要基於容易記憶容易理解的原則。保證名字的連貫性是非常重要的。
舉例來說，表單的名稱為form，那麼在匈牙利命名法中可以簡寫為frm，則當表單變數名稱為Switchboard時，變數全稱應該為frmSwitchboard。這樣可以很容易從變數名看出Switchboard是一個表單，同樣，如果此變數類型為標簽，那麼就應命名成lblSwitchboard。可以看出，匈牙利命名法非常便於記憶，而且使變數名非常清晰易懂，這樣，增強了代碼的可讀性，方便各程序員之間相互交流代碼。
這種命名技術是由一位能乾的Microsoft程序員查爾斯·西蒙尼(Charles Simonyi) 提出的，他出生在匈牙利。在 Microsoft 公司中和他一起工作的人被教會使用這種約定。這對他們來說一切都很正常。但對那些 Simonyi 領導的項目組之外的人來說卻感到很奇特，他們認為這是死板的表達方式，甚至說帶有這樣奇怪的外觀是因為它是用匈牙利文寫的。從此這種命名方式就被叫做匈牙利命名法。
據說這種命名法是一位叫 Charles Simonyi 的匈牙利程序員發明的，後來他在微軟呆了幾年，於是
這種命名法就通過微軟的各種產品和文檔資料向世界傳播開了。現在，大部分程序員不管自己使用
什麼軟體進行開發，或多或少都使用了這種命名法。這種命名法的出發點是把量名變按：屬性+類型
+對象 描述的順序組合起來，以使程序員作變數時對變數的類型和其它屬性有直觀的了解，下面
是HN變數命名規范，其中也有一些是我個人的偏向：
屬性部分
全局變數
g_
常量
c_
c++類成員變數
m_
靜態變數
s_
類型部分
指針
p
函數
fn
無效
v
句柄
h
長整型
l
布爾
b
浮點型（有時也指文件）
f
雙字
dw
字元串
sz
短整型
n
雙精度浮點
d
計數
c（通常用cnt）
字元
ch（通常用c）
整型
i（通常用n）
位元組
by
字
w
實型
r
無符號
u
描述部分
最大
Max
最小
Min
初始化
Init
臨時變數
T（或Temp）
源對象
Src
目的對象
Dest
這里順便寫幾個例子：
hwnd ： h 是類型描述，表示句柄， wnd 是變數對象描述，表示窗口，所以 hwnd 表示窗口句柄；
pfnEatApple ： pfn 是類型描述，表示指向函數的指針， EatApple 是變數對象描述，所以它表示
指向 EatApple 函數的函數指針變數。
g_cch ： g_ 是屬性描述，表示全局變數，c 和 ch 分別是計數類型和字元類型，一起表示變數類
型，這里忽略了對象描述，所以它表示一個對字元進行計數的全局變數。
上面就是HN命名法的一般規則。
小結:匈牙利命名法
匈牙利命名法
MFC、句柄、控制項及結構的命名規范 Windows類型 樣本變數 MFC類 樣本變數
HWND hWnd； CWnd* pWnd；
HDLG hDlg； CDialog* pDlg；
HDC hDC； CDC* pDC；
HGDIOBJ hGdiObj； CGdiObject* pGdiObj；
HPEN hPen； CPen* pPen；
HBRUSH hBrush； CBrush* pBrush；
HFONT hFont； CFont* pFont；
HBITMAP hBitmap； CBitmap* pBitmap；
HPALETTE hPaltte； CPalette* pPalette；
HRGN hRgn； CRgn* pRgn；
HMENU hMenu； CMenu* pMenu；
HWND hCtl； CState* pState；
HWND hCtl； CButton* pButton；
HWND hCtl； CEdit* pEdit；
HWND hCtl； CListBox* pListBox；
HWND hCtl； CComboBox* pComboBox；
HWND hCtl； CScrollBar* pScrollBar；
HSZ hszStr； CString pStr；
POINT pt； CPoint pt；
SIZE size； CSize size；
RECT rect； CRect rect；
一般前綴命名規范 前綴 類型 實例
C 類或結構 CDocument，CPrintInfo
m_ 成員變數 m_pDoc，m_nCustomers
變數命名規范 前綴 類型 描述 實例
ch char 8位字元 chGrade
ch TCHAR 如果_UNICODE定義，則為16位字元 chName
b BOOL 布爾值 bEnable
n int 整型（其大小依賴於操作系統） nLength
n UINT 無符號值（其大小依賴於操作系統） nHeight
w WORD 16位無符號值 wPos
l LONG 32位有符號整型 lOffset
dw DWORD 32位無符號整型 dwRange
p * 指針 pDoc
lp FAR* 遠指針 lpszName
lpsz LPSTR 32位字元串指針 lpszName
lpsz LPCSTR 32位常量字元串指針 lpszName
lpsz LPCTSTR 如果_UNICODE定義，則為32位常量字元串指針 lpszName
h handle Windows對象句柄 hWnd
lpfn callback 指向CALLBACK函數的遠指針
前綴 符號類型 實例 范圍
IDR_ 不同類型的多個資源共享標識 IDR_MAIINFRAME 1～0x6FFF
IDD_ 對話框資源 IDD_SPELL_CHECK 1～0x6FFF
HIDD_ 對話框資源的Help上下文 HIDD_SPELL_CHECK 0x20001～0x26FF
IDB_ 點陣圖資源 IDB_COMPANY_LOGO 1～0x6FFF
IDC_ 游標資源 IDC_PENCIL 1～0x6FFF
IDI_ 圖標資源 IDI_NOTEPAD 1～0x6FFF
ID_ 來自菜單項或工具欄的命令 ID_TOOLS_SPELLING 0x8000～0xDFFF
HID_ 命令Help上下文 HID_TOOLS_SPELLING 0x18000～0x1DFFF
IDP_ 消息框提示 IDP_INVALID_PARTNO 8～0xDEEF
HIDP_ 消息框Help上下文 HIDP_INVALID_PARTNO 0x30008～0x3DEFF
IDS_ 串資源 IDS_COPYRIGHT 1～0x7EEF
IDC_ 對話框內的控制項 IDC_RECALC 8～0xDEEF
Microsoft MFC宏命名規范 名稱 類型
_AFXDLL 唯一的動態連接庫（Dynamic Link Library，DLL）版本
_ALPHA 僅編譯DEC Alpha處理器
_DEBUG 包括診斷的調試版本
_MBCS 編譯多位元組字元集
_UNICODE 在一個應用程序中打開Unicode
AFXAPI MFC提供的函數
CALLBACK 通過指針回調的函數
庫標識符命名法 標識符 值和含義
u ANSI（N）或Unicode（U）
d 調試或發行：D = 調試；忽略標識符為發行。
靜態庫版本命名規范 庫 描述
NAFXCWD.LIB 調試版本：MFC靜態連接庫
NAFXCW.LIB 發行版本：MFC靜態連接庫
UAFXCWD.LIB 調試版本：具有Unicode支持的MFC靜態連接庫
UAFXCW.LIB 發行版本：具有Unicode支持的MFC靜態連接庫
動態連接庫命名規范 名稱 類型
_AFXDLL 唯一的動態連接庫（DLL）版本
WINAPI Windows所提供的函數
Windows.h中新的命名規范 類型 定義描述
WINAPI 使用在API聲明中的FAR PASCAL位置，如果正在編寫一個具有導出API人口點的DLL，則可以在自己的API中使用該類型
CALLBACK 使用在應用程序回叫常式，如窗口和對話框過程中的FAR PASCAL的位置
LPCSTR 與LPSTR相同，只是LPCSTR用於只讀串指針，其定義類似（const char FAR*）
UINT 可移植的無符號整型類型，其大小由主機環境決定（對於Windows NT和Windows 9x為32位）；它是unsigned int的同義詞
LRESULT 窗口程序返回值的類型
LPARAM 聲明lParam所使用的類型，lParam是窗口程序的第四個參數
WPARAM 聲明wParam所使用的類型，wParam是窗口程序的第三個參數
LPVOID 一般指針類型，與（void *）相同，可以用來代替LPSTR
B. 什麼是C語言程序設計.
（一）「項目驅動」式教學
目前最著名、最有影響、應用最廣泛的windows、linux和UNIX三個操作系統都是用C語言編寫的。0S是計算機系統(由軟硬體兩個子系統構成)的核心和靈魂，它是軟體中最龐大最復雜的系統軟體。既然如此龐大復雜的0S都可以用c語言編寫，從狹義而言，還有什麼系統軟體和應用軟體不能用c語言編寫呢?由此可以肯定的說，c語言是一門十分優秀而又重要的語言。
c語言程序設計是過程性程序設計語言，它的發展貫穿了計算機發展的歷程，它蘊含了程序設計的基本思想，囊括了程序設計的基本概念，所以它是理工科高等院校的一門基礎課程。
從市面上有關c語言的書籍和高等院校採用的教材來看，它們有一個共性，那就是：脫離了實際應用（全是小打小鬧的小例子），純粹的過程性程序設計，沒有軟體工程思想的體現，沒有一定程序設計風格，僅僅是為了讓大家明白什麼是c語言而已。
高等院校開設c語言程序設計的目的是讓學生對程序設計有個入門，有個直觀的理解，同時為其他後續課程作鋪墊。但是如果教學僅僅以此為目的，那麼教學本身就效果而言是個大大的失敗。
大家知道，在商業上講究唯利是圖，「利」是商業追求的目標，離開了「利」經商，則商無動力，其結果是必敗無疑。在c語言程序設計教學當中，教師應該把「唯用是圖」作為教學的首要目標。如果拋開了實際應用進行程序設計教學，就是紙上談兵，就是「說明書」式的教學。印度的程序設計課程採用「事件驅動式」教學，我認為在中國的c語言程序設計教學中應該採用「項目驅動式」教學。「項目驅動式」教學就是以項目為目的，以c語言理論教學為過程，最終能用c語言設計項目，實現項目的要求。「項目驅動式」教學的關鍵在於培養學生「如何做什麼」和「可以干什麼」。一個項目就是一個工程，在「項目驅動式」教學中，首先應該讓學生簡單了解什麼是軟體工程思想，其次在c語言理論教學過程中，讓學生懂得面向對象的程序設計的風格，最後引導他們來設計項目。
（二）「項目驅動」式教學應注意的問題
1.c語言程序設計教學要幫助學生樹立面向工程的觀點
在計算機行業中，軟體是通過人們的智力活動、把知識與技術轉化成信息的一種產品。軟體的設計已經用工程的觀念來進行管理。軟體設計工作被當作一項系統工程來對待。軟體的的生存周期一般可分為以下階段：問題定義、可行性研究、需求分析、概要設計、詳細設計、編碼、測試、運行與維護。我們不難看出軟體工程的復雜程度是很大的。理工科高等院校把c語言作為一門基礎課程，也是為了給社會培養信息技術人才。眾所周知，養成一個好的習慣是非常重要的，所以c語言程序設計作為大多數工科院校學生接觸的第一門程序設計語言（有的院校講pascal），就應該讓學生樹立正確的觀點。那麼當前的程序設計教學也必須以切合將來軟體工程開發的實際需要為第一目標，使學生在學習程序設計的初級階段就樹立正確的軟體工程觀點。這樣做不僅可以為學生將來從事計算機應用設計打下良好的基礎，而且有利於培養學生分析問題的完備性，以及統籌全局，協調關系的基本素質。
2.理論教學應從單一的「結構化程序設計」向「結構化與面向對象並舉」轉變
「結構化程序設計」方法是程序設計的基礎，必須讓學生掌握得堅實可靠。結構化程序設計的過程是培養學生思維能力的過程，在教學中經常發現有些學生的思維混亂。這些都是缺乏思維訓練的結果。結構化程序設計的訓練不僅可以讓學生養成良好的程序設計習慣，而且可以有效地培養學生思維的條理性和邏輯性。所以在授課過程中要注意講解結構化程序設計的思想時應突出兩點：（1）程序的質量首先取決於它的結構。（2）程序設計的基本方法是自頂向下地逐步求精和模塊化。
在c程序教學過程中，越到後面的章節，學生越會產生設計程序逐漸變難的感覺，這是不符合邏輯的一種怪現象。按照常理，C語言學的越多，說明你的程序設計知識越多，設計起程序來應該更加得心應手，那麼出現這種現象的原因何在呢？當然該問題的出現的原因是多方面的，但是其中最重要的一點就是長期以來程序設計的觀念不是以如何處理好對象為出發點，而是以如何使用好語言為基本點。受這種思想的影響，我們的程序設計教學大多數不是以如何解決好問題為重點，而是以講解語法規則和語句格式為重點，是「說明書」式的教學。這樣做造成的結果就是見到一個程序後學生首先想到是該用哪條語句，而不是思考怎樣合理的解析。要切實解決這個問題，首先應該改變程序設計的觀念。「面向對象程序設計」思想是目前最為流行、極為實用的一種程序設計方法，但是讓學生直接接觸「面向對象程序設計」，肯定不能對程序設計打下牢固的基礎。「結構化與面向對象並舉」是現代計算機程序設計的發展趨勢，應該認真探索研究，讓學生有一個較為輕松的學習過程。程序設計的實質就是編寫處理對象的過程，所以將c與c++有機的融為一體的教材應該是首選教材，在教學過程中，我們應該從社會發展的角度進行探索研究，將目前最為流行又極為實用「面向對象程序設計」思想融合到c語言教學中。
3.c語言教學應培養學生良好的程序設計風格
具有良好的設計風格應該是程序員所具備的基本素質，在實際的項目中程序員往往都有自己的一些編程風格。目前95％以上的程序設計書籍不注重程序設計風格問題，這導致了很多學生沒有良好的程序設計風格，在他們剛剛畢業踏入社會時，如果周圍的同事沒有良好的編程風格，那麼很難通過環境來使自己提高這方面的素質，即使有提高也不容易比較全面的提高。因此在學生接觸的第一門程序設計語言教學中，就應該培養學生良好的程序設計風格，使他們一進工作環境就具備這個素質。
Pascal設計者N.Writh教授十分重視程序設計風格的養成，他堅信「教給學生們以表達他們思維的語言會深深地影響他們思維和創造發明的習慣，而正是這些語言本身的混亂直接影響著學生們的程序設計的風格」，他這里所指的「這些運用」是當時那些主要用於程序設計教學的計算機語言。對學生來講，一開始就強調程序設計風格很有必要，良好的程序設計風格不僅有助於提高程序的可靠性、可理解性、可測試性、可維護性和可重用性，而且也能夠促進技術的交流，改善軟體的質量。所以培養良好的程序設計風格對於初學者來說非常重要。
程序設計風格，實際上是指的是編碼風格。在教學過程中應從源程序文檔化，數據說明的原則，輸入／輸出方法這三個方面培養學生的編碼風格，進而從編碼原則探討提高程序的可讀性、改善程序質量的方法。
（1）源程序文檔化。編碼的目的是產生程序，但是為了提高程序的可維護性。源代碼是需要實現文檔化的。源程序文檔化包括選擇標識符(變數和標號)的名字、安排注釋以及標準的書寫格式等。
①選擇標識符的命名規則。標識符包括模塊名、變數名、常量名、標號名、子程序名等。這些名字應能反映它所代表的實際東西，應有一定實際意義，使其能顧名思義。另外在模塊名、變數名、常量名、標號名、子程序名中使用下劃線是一種風格。使用這一技術的一種廣為人知的命名規則就是匈牙利命名法（變數類型由一個或兩個字元表示，並且這些字元將作為變數名的前綴）。當然使用匈牙利命名法與否都沒有錯誤，重要的是要保持一致性——在整個程序中使用相同的命名規則。這就是說，如果你在一個小組環境中編程，你和其他小組成員應該制定一種命名規則。並自始至終使用這種規則。如果有人使用了別的命名規則，那麼集成的程序讀起來將是很費勁的。此外，你還要與程序中用到的第三方庫（如果有的話）所使用的風格保持一致。如果可能的話，你應該盡量使用與第三方庫相同的命名規則，這將加強你的程序的可讀性和一致性。
②注釋。程序中的注釋是程序設計者與程序閱讀者之間通信的重要手段。注釋能夠幫助讀者理解程序，並為後續測試維護提供明確的指導信息。因此，注釋是十分重要的，大多數程序設計語言提供了使用自然語言來寫注釋的環境，為程序閱讀者帶來很大的方便。注釋分為功能性注釋和序言性注釋。
a.功能性注釋。功能性注釋在源程序中，用以描述其後的語句或程序段是在做什麼工作，也就是解釋下面要「做什麼」，而不是解釋下面怎麼做。對於書寫功能性注釋，要注意以下幾點：第一描述一段程序，而不是每一個語句。第二利用縮進和空行，使程序與注釋容易區別。第三注釋要准確無誤。
b.序言性注釋。序言性注釋通常位於每個程序模塊的開頭部分，它給出程序的整體說明，對於理解程序具有引導作用。有些軟體開發部門對序言性注釋做了明確而嚴格的規定，要求程序編制者逐項列出。有關內容包括：程序標題；有關該模塊功能和目的的說明；主要演算法；介面說明：包括調用形式，參數描述，子程序清單；有關數據描述；模塊位置(在哪一個源文件中，或隸屬於哪一個軟體包)；開發簡歷：模塊設計者、復審考、復審日期。
③用標準的書寫格式。源程序清單的書寫建議採用以下幾點：
a.每行只寫一條語句；
b.用分層縮進的寫法顯示嵌套結構層次，這樣可使程序的邏輯結構更加清晰，層次更加分明。
c.書寫表達式時適當使用空格或圓括弧作隔離符。
d.在注釋段周圍加上邊框；
e.注釋段與程序段、以及不同的程序段之間插入字行；
（2）數據說明採用的原則。在編寫程序時，要注意數據說明的風格。
數據說明的次序如果規范，將有利於測試，排錯和維護。首先說明的先後次序要固定，例如，按常量說明、簡單變數類型說明、數組說明用數據塊說明、所有的文件說明的順序說明。當然在類型說明中還可進一步要求，例如按如下順序排列：整型量說明、實型量說明、字元量說明、邏輯說明。
其次當用一個語句說明多個變數名時，應當對這些變數按字母的順序排列。
最後對於復雜數據結構，應利用注釋說明實現這個數據結構的特點。
（3）輸入／輸出方法。輸入／輸出的方式和格式應當盡量避免因設計不當給用戶帶來的麻煩。這就要求，源程序的輸入／輸出風格必須滿足能否為用戶接受這一原則。所以在設計程序時，應考慮以下原則：輸入數據時，要使輸入的步驟和操作盡可能簡單，應允許使用自由格式輸入；應允許預設值；對輸入的數據要進行檢驗，以保證每個數據的有效性。
（三）結束語
在教學過程中，我們讓學生設計一個程序模擬體育彩票的銷售與對獎的過程，取得了良好的效果。他不僅啟發和誘導了學生獨立思考、積極思維的主動性，而且充分調動了學生學習的自覺性和積極性，使學生融會貫通地掌握了所學知識，提高了分析問題和解決實際問題的能力。
搞好c程序設計的教學工作涉及的因素很多，如果以項目來驅動教學，首先讓學生樹立面向工程的思想，其次把教學從單一的「結構化程序設計」向「結構化與面向對象並舉」轉變，最後特別要培養學生養成良好的編碼風格，從而使他們學會能夠「干什麼」，那麼我們認為教學目的就達到了
C. C語言的編程思想是什麼
C語言是面向過程的編程方法，所有功能都是靠函數來實現。學C語言就是讓你了解面向過程的編程思想和一些基本的編程演算法，為以後學習面向對象的編程打下扎實的基礎
D. 關於編程風格
首先,編程風格並不同於其他的style，目的並不是形成自己獨樹一幟的風格，而是為了讓你的程序易讀,有利於團隊合作以及別人幫你改錯。
風格是通用的
C語言和C++語言的編程風格 （java見下）
第一章:縮進格式
Tab是8個字元,於是縮進也是8個字元.有很多怪異的風格,他們將縮進格式定義為4個字元(設置為2個字元!)的深度,這就象試圖將PI定義為3一樣讓人難以接受.
理由是:縮進的大小是為了清楚的定義一個塊的開始和結束.特別是當你已經在計算機前面呆了20多個小時了以後,你會發現一個大的縮進格式使得你對程序的理解更容易.
現在,有一些人說,使用8個字元的縮進使得代碼離右邊很近,在80個字元寬度的終端屏幕上看程序很難受.回答是,但你的程序有3個以上的縮進的時候,你就應該修改你的程序.
總之,8個字元的縮進使得程序易讀,還有一個附加的好處,就是它能在你將程序變得嵌套層數太多的時候給你警告.這個時候,你應該修改你的程序.
第二章:大符號的位置
另外一個C程序編程風格的問題是對大括弧的處理.同縮進大小不同,幾乎沒有什麼理由去選擇一種而不選擇另外一種風格,但有一種推薦的風格,它是Kernighan和Ritchie的經典的那本書帶來的,它將開始
的大括弧放在一行的最後,而將結束大括弧放在一行的第一位,如下所示:
if (x is true) { we do y }
然而,還有一種特殊的情況:命名函數:開始的括弧是放在下一行的第一位,如下:
int function(int x) { body of function }
所有非正統的人會非難這種不一致性,但是,所有思維正常的人明白: (第一) K&R是___對___的,(第二)如果K&R不對,請參見第一條. (:-))......另外,函數也是特殊的,不一定非得一致.
需要注意的是結束的括弧在它所佔的那一行是空的,__除了__它跟隨著同一條語句的繼續符號.如"while"在do-while循環中,或者"else"在if語句中.如下:
do { body of do-loop } while (condition);
以及
if (x == y) { .. } else if (x > y) { ... } else { .... }
理由: K&R.
另外,注意到這種大括弧的放置方法減小了空行的數量,但卻沒有減少可讀性.於是,在屏幕大小受到限制的時候,你就可以有更多的空行來寫些注釋了.
第三章:命名系統
C是一種簡潔的語言,那麼,命名也應該是簡潔的.同MODULE-2以及ASCAL語言不同的是,C程序員不使用諸如之類的命名方式.一個C語言的程序員會將之命名為"tmp",這很容易書寫,且並不是那麼難以去理解.
然而,當混合類型的名字不得不出現的時候,描述性名字對全局變數來說是必要的了.調用一個名為"foo"全局的函數是很讓人惱火的.全局變數(只有你必須使用的時候才使用它) ,就象全局函數一樣,需要描述性的命名方式.假如你有一個函數用來計算活動用戶的數量,你應該這樣命名--"count_active_users()"--或另外的相近的形式,你不應命名為"cntusr()".
有一種稱為Hungarian命名方式,它將函數的類型編碼寫入變數名中,這種方式是腦子有毛病的一種表現---編譯器知道這個類型而且會去檢查它,而這樣只會迷惑程序員. --知道為什麼Micro$oft為什麼會生產這么多"臭蟲"程序了把!!.
局部變數的命名應該短小精悍.假如你有一個隨機的整數循環計數器,它有可能有"i",如果沒有任何可能使得它能被誤解的話,將其寫作"loop_counter"是效率低下的.同樣的,""tmp"可以是任何臨時數值的函數變數.
如果你害怕混淆你的局部變數的名字,還有另外一個問題,就是稱
function-growth-hormone-imbalancesyndrome.
第四章:函數
函數應該短小而迷人,而且它只作一件事情.它應只覆蓋一到兩個屏幕(80*24一屏),並且只作一件事情,而且將它做好.(這不就是UNIX的風格嗎,譯者注).
一個函數的最大長度和函數的復雜程度以及縮進大小成反比.於是,如果你已經寫了簡單但長度較長的的函數,而且你已經對不同的情況做了很多很小的事情,寫一個更長一點的函數也是無所謂的.
然而,假如你要寫一個很復雜的函數,而且你已經估計到假如一般人讀這個函數,他可能都不知道這個函數在說些什麼,這個時候,使用具有描述性名字的有幫助的函數.
另外一個需要考慮的是局部變數的數量.他們不應該超過5-10個,否則你有可能會出錯.重新考慮這個函數,將他們分割成更小的函數.人的大腦通常可以很容易的記住7件不同的事情,超過這個數量會引起混亂.你知道你很聰明,但是你可能仍想去明白2周以前的做的事情.
第5章:注釋
注釋是一件很好的事情,但是過多的注釋也是危險的,不要試圖區解釋你的代碼是注釋如何如何的好:你應該將代碼寫得更好,而不是花費大量的時間去解釋那些糟糕的代碼.
通常情況下,你的注釋是說明你的代碼做些什麼,而不是怎麼做的.而且,要試圖避免將注釋插在一個函數體里:假如這個函數確實很復雜,你需要在其中有部分的注釋,你應該回到第四章看看.你可以寫些簡短的注釋來註明或警告那些你認為特別聰明(或極其醜陋)的部分,但是你必須要避免過多.取而代之的是,將注釋寫在函數前,告訴別人它做些什麼事情,和可能為什麼要這樣做.
第六章:你已經深陷其中了.
不要著急.你有可能已經被告之"GUN emacs"會自動的幫你處理C的源代碼格式,而且你已經看到它確實如此,但是,預設的情況下,它的作用還是不盡如人意(實際上,他們比隨便敲出來的東西還要難看- ainfinite number of monkeys typing into GNU emacs would never make a good program)
於是,你可以要麼不要使用GUN emacs,要麼讓它使用sanervalules.使用後者,你需要將如下的語句輸入到你的.emacs文件中.(defun linux-c-mode() "C mode with adjusted defaults for use with the Linux kernel."(interactive) (c-mode) (c-set-style"K&R") (setq c-basic-offset8))
這會定義一個M-x Linux-c-mode的命令.當你hacking一個模塊的時候,如何你將-*- linux-c -*-輸入在最開始的兩行,這個模式會自動起作用.而且,你也許想加入如下
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*.〖ch〗$" . linux-c-mode) auto-mode-alist))
到你的.emacs文件中,這樣的話,當你在/usr/src/linux下編輯文件的時候,它會自動切換到linux-c-mode .
但是,假如你還不能讓emaces去自動處理文件的格式,不要緊張,你還有一樣東西: "縮進" .
GNU的縮進格式也很死板,這就是你為什麼需要加上幾行命令選項.然而,這還不算太壞,因為GNU縮進格式的創造者也記得K&R的權威, (GNU沒有罪,他們僅僅是在這件事情上錯誤的引導了人們) ,你要做的就只有輸入選項"-kr -i8"(表示"K&R,縮進8個字元).
"縮進"有很多功能,特別是當它建議你重新格式你的代碼的時候,你應該看看幫助.但要記住: "縮進"不是風格很差的程序的萬靈丹.
http://www.nou.com.cn/portal/Article/itjs/jsjj/cxsj/200511/20051104115145.html
JAVA編程風格簡析
很久以來都在體會著JAVA的風格，現在做一簡單陳述，希望大家多提寶貴意見。
對於一種好的編程語言，學習它的編程風格是很重要的。每種語言都有自己的編寫和注釋約定，當然所有語言都建立在最基本的約定之上。編程中最重要的並不是讓代碼按自己希望的方式運行，而是程序中那種自明的編程風格（這對於程序員的益處相信眾多程序員都身有體會）！但這還不夠，程序還應該具有可讀、相對持久和可維護性。可讀性非常重要，因為你不希望自己以前的作品在之後的閱讀中給自己留下障礙，當然，更重要的是自己的程序能讓其他程序員讀懂並且修改。
下面我把工作中所理解的java風格做一簡單總結，這是我所理解的好的編程風格和應用中我們應當如何使用java編寫自己的代碼的小Guide。這並不完全，希望大家幫我陸續總結各自的經驗。
一般性概述
好的編程風格固然重要，但是你一定聽說過一些程序員的個人風格。其實我們完全不必為那些所謂條條框框所累，但是作為原則是我們至少不能打破這些常規。我們應該在保持自己風格的同時盡量的把自己與編程潛原則靠攏。
可讀性很容易達到，比如，讓自己的代碼縮排排列、名字採用描述性但不要過長（短名應僅僅用在非遠程）、特殊名稱比如pi應當被定義為final類型。模塊性是編程需要注意的另一重點，把代碼劃分到類里，在類中把功能劃分到方法中，別讓一個類太大，否則在使用、修改和理解上都會造成不必要的麻煩，方法也一樣，如果一個方法長度超過50行，它產生錯誤的概率將接近100％，盡量把大方法劃分為小方法，編程中為避免重復編寫，還應盡量調用JAVA標准類庫。
盡量避免在寫代碼和注釋時使用不同語言，經常見到論壇有朋友詢問諸如在java中調用c、調用php、調用shell之類的問題，其實在編程中，我們應盡量使用一種語言去完成事情。另外就是不必最優化自己的代碼，應該選擇相對較優的演算法就可以了。
類、方法和fields
類應體現出某種物質的基本概念，比如要編程實現「汽車」的組成，那麼所有的汽車都可以用類Car實現。這個類應當包括域描述、屬性描述和car的狀態（color, number of doors, age等）和由car可完成的操作（getColor, setColor等）。為了提高類的可重用性，不要在類中有過多的描述，當然這也會增加錯誤產生的機會。
類名首字母大寫，比如Date, String, Hashtable等 ... ...
類如下定義：(未使用Javadoc做注釋):
public class Car {
/* Instance variables are placed either in the beginning
or at the end of the class */
private int age;
private Color color;
/* The constructor should be placed in the beginning */
public Car(int age, Color color) {
this.age = age;
this.color = color;
}
/* Example method */
public int getAge() {
return age;
}
/* The main method is optional, but looks like this.
If it exists, it is either the first or the last
method in the class */
public static void main(String [] args) {
...
}
}
注意類名和大括弧間的空格！
方法
方法一般定義為public。當然，如果方法僅僅在當前類用到可以定義為private，而如果希望一個子類沿用這個方法則不同，這時候的方法應定義為protected。
java中的方法定義很有趣，它們一般小寫字母開頭，如果有兩個字組成，第二個字的首字母則大寫。因此名字的描述性是至關重要的。這使你不用閱讀整篇代碼來判斷這是一個什麼方法。在給自己的方法取名時應盡量不要太短或者太長，另一個需要注意的是大多方法使用動詞（動賓短語）。
例如：
public void eat() {}
public void eatBananas() {}
Selector（選擇器）方法有get前綴，後綴是它們將要get的，比如
public int getBananas() {}
Mutator（存取器）方法則有set前綴，後綴則是他們要set的，比如
public void setBananas(int amount) {}
注意mutators大多無返回值。
方法的參數應當以如下方式給出：
public void aMethod(type parameter1, type parameter2, ... , type parametern) {}
如果參數過長，也可以斷開為幾行，應對齊向下排列如：
public void aMethod(type parameter1, type parameter2,... ,
type parametern, type parameter n+1,... ,
type parameterm, type parameter m+1) {}
另外要注意類的左束括弧應在方法的右束括弧之後而非下一行:
public int aMethod() {
int i = 0;
if(i == 0)
System.out.println("success！");
}
為了文件可讀性好，還要注意語句最好寫在同一行，當然一行寫不下是可以斷行的，比如行字母超過80。
fields
比如變數，如果不希望它永久有效，應設為private。如果一個變數在類中不發生任何動作（比如數據結構中的node）則可以設置為public，常量一般聲明為public。如果不能確定一個變數到底該聲明為什麼，應暫且聲明為private。
field的名字一般使用小寫字母，不要使用下橫線或其他特殊字元。 如果變數包含兩個字，那麼第二個字的首字母大寫。比如：
int i, j, k;
Date date;
double myField;
常量一般全部大寫，也可以包含下橫線：
public static final int MAX_SIZE_OF_DATABASE
fields的名字通常為名詞。較重要的fields更應具備描述性，比如程序中包含一個游戲的得分，那可以用score來代表。如果變數變化較頻繁，那使用一個單一字元來代表就ok了：
i, j, k 通常代表整數
r, t, u, v, w 通常代表實數
x, y, z 通常是並列出現或代表浮點數
s, s1, s2, 通常代表字元串
c, ch 通常代表字元
f, file 通常代表文件
tmp, temp 通常代表臨時變數
ctr, cnt, cntr 一般代表計數器(如果i, j, k這些變數已被使用)
mmy, foo, bar 一般代表啞元變數
args 是main-method的主參數名
縮排與換行
每行長度不得超過80字元。如果需要可以折行時，也應當與上一行有共同的縮排距離。代碼應如何交錯、如何建立新行、在哪裡建立允許、哪裡不允許都有一些一般約定，縮排空格一般為2個或4個空格。
條件表達式
如果見到如下語法表達式：
if (expr)
statement1;
else
statement2;
代碼行向右錯排兩個空格如上所示。
如果在一個表達式中有超過一條的聲明，則需要大括弧:
if (expr){
statement1;
statement2;
} else{
statement3;
statement4;
}
有時我們會希望在表達式中使用表達式（比如條件嵌套），這時應注意else表達式，它的位置很容易出錯！如例：
if (expr1) {
statement1;
statement2;
} else if (expr2)
statement3;
else if (expr3) {
statement4;
statement5;
} else {
statement6;
statement7;
}
注意大括弧位置！
Loops
while-loop語法如下：
while (expr) {
statement1;
statement2;
}
for-loop語法如下：
for (expr1; expr2; expr3){
statement1;
statement2;
}
注意大括弧位置！僅一條聲明時大括弧省略：
while (expr)
statement;
for (expr1; expr2; expr3)
statement;
例如，我們寫一個procere寫出1到10這十個數字：
for (i = 1; i <= 10; i++)
System.out.println(i);
try-catch語法形如：
try {
statements;
} catch (ExceptionClass e) {
statements;
}
如果try-catch語句後跟隨finally子句則形如：
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
新行
每一行最好只闡述一件事情。比如，一行包含一個聲明、一個條件語句、一個循環等。不論多小，最好不要一行辦兩件事及以上。例如不要把一個if表達式或循環語句的主體放置在同一行，這樣的表達式斷行的易讀性會更高。通常，互相協作的代碼應放在一起，為保證代碼美觀可讀，我們應將代碼的不同代碼段放置在不同的段落。不過要牢記斷行不要太過分！比如:
public int factorial(int n) {
int result = 1;
for(int i = 1; i <= n; i++)
result*=i;
return result;
}
給自己的代碼加入注釋
注釋就是類的描繪、方法存在的原因、它完成了什麼以及它對它其中（變數）的作用域。假定閱讀你代碼的人已經知道這是什麼語言，所以不需要注釋語句功能，盡量使用簡短而有描述力的注釋。
Java有兩種類型的注釋：
//This is a comment that continues until the end of the line.
/* This is a comment. It goes on and on and on and on and on and on and on
and on and on and on and on and on and on and on and on and on and on and
on and on and on and on and on and on and on and on and ends like this: */
/**
* This is a JavaDoc comment. More about JavaDoc in the next section.
*/
如果在注釋中加入注釋則會出錯：
/* You are not allowed to do anything like this /* because the compiler will
complain, if you are lucky */ DON'T DO THIS! And don't write comments in
upper case either... */
注釋應放在它要解釋內容上下，這樣會讓代碼更易於理解。
不要注釋一些語言的語句功能：
i++; // Add 1 to i
更不要讓自己的代碼處於這種狀態：
for(int i = 1; i <= n; i++)
/* don't place comments where
they don't belong */
result*=i;
較短的注釋既可被放在被注釋代碼上下，而長注釋則習慣性的放在代碼之上：
/* Comments can be placed before the
block that is to be commented */
for(int i = 1; i <= n; i++)
result*=i;
或者:
for(int i = 1; i <= n; i++){
result*=i; // short comments can be placed like this
tmp++; // if necessary, they continue here
}
不要寫沒用的注釋：
i++; // change this later
Excuse me,這句肯定是胡扯！
不要寫自己都看不懂的注釋：
i++; // BMW
BMW? 如果你能連續十天記住這是什麼意思的話，那麼你的記憶真是不錯了。所以不要寫沒人能看懂的注釋，ok？
最後重申一下：寫簡短而富於描述性的注釋，把它們放在該放的地方，而不要考驗你自己的記憶力！
JavaDoc - 文檔工具
JavaDoc不僅是另一種給代碼加註釋的彷彿咱，更是一個文檔工具。類、方法和一些重要地方需要用JavaDoc來注釋。這並不是說你可以放棄常規的注釋，這兩者在代碼中應該是相輔相成、互相彌補的關系。
類被注釋如：
/**
* Car represents cars ... A description of the class
* should be place here. Note that the description begins
* on the second line and that there is a space between
* the asterix and the text. Next we will add some fields
* indicating who the authors of the class are and
* other useful information. Notice the newline!
*
* @author Jerry Meng
* @version %I%, %G%
*/
public class Car {
注意JavaDoc結束和類開始間無空行。
方法被注釋如：
/**
* A description of what the method does...
*
* @param n a description of the parameter
* @return a description of the return value
*/
public int factorial(int n) {
某些不是全部，被JavaDoc注釋區域如：
/**
* Short description of the variable (one line)
*/
type variable;
什麼應當使用JavaDoc做注釋？如何注釋的恰當呢？
可以這樣想，JavaDoc中所作的注釋都可以在類的文檔中看到。所有讀這個類的文檔的讀者都會明白這個類所完成的功能、它包括的方法、如何使用這些方法及方法的返回值。一些作用域，比如public的變數或常量將會一目瞭然。任何不了解這個類內部結構的人都可以輕松的調用它。這便是你用JavaDoc可以輕松提供的信息。而使用一般注釋的地方，一般是給那些可能修改你的類代碼的程序員，它們一般描述了類的內部信息和結構。
下面我寫一下car的類來描述一個編程風格好的java類應該是怎樣的。當然這僅僅是一個小例子(apart from selector and mutator methods)，僅僅是在考慮JAVA編程風格上一個參考而已。
import java.awt.Color;
/**
* This is a class representing cars. A car has certain features, such
* as color, age, number of doors etc and a car can be repainted,
* the tank can be filled etc.
*
* @author Jerry Meng
* @version %I%, %G%
*/
public class Car {
/**
* The maximum size of the tank in litres.
*/
private static final double TANK_SIZE = 100.0;
/**
* The color of the car.
*/
private Color color;
/**
* The age of the car.
*/
private int age;
/**
* The number of doors of the car.
*/
private int doors;
/**
* The amount of gasoline in the tank.
*/
private double gasoline;
/**
* Class constructor, which constructs a brand new, black car with
* five doors and a full tank.
*/
public Car() {
this(Color.black, 0, 5, TANK_SIZE);
}
/**
* Class constructor specifying the color, age, number of doors
* and litres of gasoline
*
* @param color The color of the car
* @param age The age of the car
* @param doors The number of doors
* @param km Kilometres driven
* @param gasoline The litres of gasoline
*/
public Car(Color color, int age, int doors, double gasoline) {
this.color = color;
this.age = age;
this.doors = doors;
this.gasoline = gasoline;
}
/**
* Returns the color of the car
*/
public Color getColor() {
return color;
}
/**
* Repaints the car (i.e. changes its color)
*/
public void setColor(Color color) {
this.color = color;
}
/**
* Returns the age of the car
*/
public int getAge() {
return age;
}
/**
* Returns the number of doors of the car
*/
public int getDoors() {
return doors;
}
/**
* Returns the amount of gasoline in the tank
*/
public double getGasoline() {
return gasoline;
}
/**
* Fills the tank. The amount of gasoline cannot exceed
* the size of the tank. In that case, the tank will be
* filled to the maximum and the rest will run out in
* the sand.
*
* @param gas The amount of gasoline to put in the tank
*/
public void setGasoline(double gas) {
if(gasoline + gas <= TANK_SIZE)
gasoline+=gas;
else
gasoline = TANK_SIZE;
}
}
http://www.chinaunix.net/jh/26/511939.html
http://book.csdn.net/bookfiles/170/1001707562.shtml
E. C語言優秀編程風格是什麼樣子
這些C語言版本不僅實現了ANSIC標准，而且在此基礎上各自作了一些擴充，使之更加方便、完美。回答者：-10-1314:34C語言是一種通用的程序設計語言,由於其功能非常強大,因此可以用來完成一些非常復雜的工作.很多操作系統都是用C語言編寫的,例如:UNIX,MS-DOS,MicrosoftWindows,Linux等.C語言具有高效,靈活,功能豐富,表達力強和移植性好等特點.回答者：-10-1315:40C語言的發展史和演變史就不多說了！首先C語言是屬於高級語言（在這之前有機器語言，匯編語言）其次C語言的特點是面向結構再次它執行的特點是指至頂向下逐行執行！