淺談C++規范化編程規范化編程的意義※對于團隊開發每個人都有自己的想法，每個人都有自己的代碼風格，如果沒有一個約束大家的規范，整個項目的開發必然一團糟。為了能夠使整個項目能夠正常地進行，并且保證項目質量，我們需要規范化的編程。

※對于小型項目

在座的同事，都能按照項目的需求，在項目交付日期前，完成軟件的開發工作。所以從技術上來說，各位都算得上是高手?！椖康难永m性、可讀性也要求進行規范，便于后續的維護管理。規范化編程——排版規則1：程序塊要采用縮進風格編寫，縮進

的空格數為4個，不要使用Tab縮進，因為不同的編輯器會有不同的解釋。說明：由開發工具自動生成的代碼可以不一致。規則2：縮進或者對齊只能使用空格鍵，不可使用TAB鍵。Tab配置：工具—>選項—>文本編輯器—>C/C++—>制表符規范化編程——排版規范化編程——排版規則3：相對獨立的塊之間、變量說明之后必須加空行。說明：以下情況應該用空行隔開1）函數之間應該用空行分開；2）變量聲明應盡可能靠近第一次使用處，避免一次性聲明一組沒有馬上使用的變量；3）用空行將代碼按照邏輯片斷劃分；4）每個類聲明之后應該加入空格同其他代碼分開。規范化編程——排版示例：規范化編程——排版規則4：較長的語句（>80字符）要分成多行書寫。說明，以下情況應分多行書寫：1）長表達式要在低優先級操作符處劃分新行，操作符放在新行之首，劃分出的新行要進行適當的縮進，使排版整齊，語句可讀。2）若函數或過程中的參數較長，則要進行適當的劃分。3）循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分，長表達式要在低優先級操作符處劃分新行，操作符放在新行之首。規范化編程——排版規范化編程——排版規則5：不允許把多個短語句寫在一行，一行只寫一條語句。說明：一行代碼只做一件事情，如只定義一個變量，或只寫一條語句。這樣的代碼容易閱讀，并且方便于寫注釋。

規則6：if、for、do、while、case、switch、default等語句自占一行，且if、for、do、while等語句的執行語句部分無論多少都要加括號{}。規范化編程——排版建議7：代碼行之內應該留有適當的空格說明：采用這種松散方式編寫代碼的目的是使代碼更加清晰。代碼行內應該適當的使用空格，具體如下：

1）關鍵字之后要留空格。象const、virtual、inline、case等關鍵字之后至少要留一個空格，否則無法辨析關鍵字。象if、for、while等關鍵字之后應留一個空格再跟左括號‘（’，以突出關鍵字。

2）函數名之后不要留空格，緊跟左括號’(’，以與關鍵字區別。

3）‘(’向后緊跟，‘)’、‘，’、‘;’向前緊跟，緊跟處不留空格。

4）‘,’之后要留空格，如Function(x,y,z)。如果‘;’不是一行的結束符號，其后也要留空格，如for(initialization;condition;update)。

5）值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“=”、“+=”

“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”、“^”等二元操作符的前后應當加空格。

6）一元操作符如“!”、“~”、“++”、“--”、“&”（地址運算符）等前后不加空格。

7）象“［］”、“.”、“->”這類操作符前后不加空格。8）對于表達式比較長的for語句和if語句，為了緊湊起見可以適當地去掉一些空格，如for(inti=0;i<10;++i)規范化編程——排版建議8：程序塊的分界符（如C/C++語言的大括號‘{’和‘}’）應各獨占一行并且位于同一列，同時與引用它們的語句左對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要采用如上的縮進方式規范化編程——注釋注釋的原則：

有助于對程序的閱讀理解，在該加的地方都要加，注釋不宜太多也不太少，一般情況下，源程序的有效注釋量應該在20%以上。注釋語言必須準確、易懂、簡潔。注釋語言在同一項目中必須一致，不能中英混雜（對英文縮寫的英文注釋除外）。規范化編程——注釋規則1：說明性文件（如頭文件.h文件、.inc文件、.def文件、編譯說明文件.cfg等）頭部應進行注釋。注釋必須列出：版權說明、版本號、生成日期、作者、內容、功能、與其它文件的關系、修改日志等，頭文件的注釋中還應有函數功能簡要說明。在實際工作中，每個類的函數不會太多，函數列表可以省略，只要寫清楚函數的注釋就行。規范化編程——注釋規則2：源文件頭部應進行注釋，列出：生成日期、作者、模塊目的/功能等。說明：同樣的，函數列表建議可以省略，但是函數的注釋要寫清楚。示例：下面這段源文件的頭注釋比較標準，可以不局限于此格式，但上述信息要包含在內。/*********************************************************Copyright(C),1988-1999,SynthesisCo.,Ltd.FileName:test.cppAuthor://編寫人Version://版本號Date://生成日期Description://模塊描述Version://版本信息FunctionList://主要函數及其功能1.-------History://歷史修改記錄<author><time><version><desc>David96/10/121.0buildthismoudle********************************************************/規范化編程——注釋規則3：函數頭部應進行注釋，列出：函數的目的/功能、輸入參數、輸出參數、返回值、調用關系（函數、表）等。示例：同樣的，建議普通函數可以不用注釋紅色部分。/**********************************************Function://函數名稱Description://函數功能、性能等的描述Calls://被本函數調用的函數清單CalledBy://調用本函數的函數清單TableAccessed://被訪問的表（此項僅對于牽扯到數據庫操作的程序）TableUpdated://被修改的表（此項僅對于牽扯到數據庫操作的程序）Input://輸入參數說明，包括每個參數的作用、取值說明及參數間關系。Output://對輸出參數的說明。Return://函數返回值的說明Others://其它說明**********************************************/規范化編程——注釋規則3：注釋應該和代碼同時更新，不再有用的注釋要刪除。規則4：注釋的內容要清楚、明了,不能有二義性.規則5：避免在注釋中使用非常用的縮寫或者術語。建議6：注釋的主要目的應該是解釋為什么這么做，而不是正在做什么。建議7：避免非必要的注釋。ClassA*pA=newClassA();//創建新實例規范化編程——注釋規則8：注釋的版式說明：注釋也需要與代碼一樣整齊排版1）注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，不可放在下面，如放于上方則需與其上面的代碼用空行隔開。2）注釋與所描述內容進行同樣的縮排。3）將注釋與其上面的代碼用空行隔開。4）變量、常量、宏的注釋應放在其上方相鄰位置或右方。示例：如下例子不符合規范。規范化編程——注釋規范化編程——注釋規則9：對于所有有物理含義的變量、常量，如果其命名不是充分自注釋的，在聲明時都必須加以注釋，說明其物理含義。規則10：數據結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋的，必須加以注釋。對數據結構的注釋應放在其上方相鄰位置，不可放在下面；對結構中的每個域的注釋可放在此域的右方。建議11：對重要變量的定義需編寫注釋，特別是全局變量，更應有較詳細的注釋，包括對其功能、取值范圍、以及存取時注意事項等的說明。規范化編程——注釋規則12：分支語句（條件分支、循環語句等）需編寫注釋。說明：這些語句往往是程序實現某一特定功能的關鍵，對于維護人員來說，良好的注釋幫助更好的理解程序，有時甚至優于看設計文檔。規則13：對于switch語句下的case語句，如果因為特殊情況需要處理完一個case后進入下一個case處理，必須在該case語句處理完、下一個case語句前加上明確的注釋。說明：這樣比較清楚程序編寫者的意圖，有效防止無故遺漏break語句。規范化編程——注釋規則14：避免在一行代碼或表達式的中間插入注釋。規則15:：通過對函數或過程、變量、結構等正確的命名以及合理地組織代碼的結構，使代碼成為自注釋的。說明：清晰準確的函數、變量等的命名，可增加代碼可讀性，并減少不必要的注釋。規則16：在代碼的功能、意圖層次上進行注釋，提供有用、額外的信息。說明：注釋的目的是解釋代碼的目的、功能和采用的方法，提供代碼以外的信息，幫助讀者理解代碼，防止沒必要的重復注釋信息。規則17：在程序塊的結束行右方加注釋標記，以表明某程序塊的結束。說明：當代碼段較長，特別是多重嵌套時，這樣做可以使代碼更清晰，更便于閱讀。規則18：注釋格式應統一，單獨的注釋使用“/*……*/”，代碼行中的注釋使用“//”。使用“//”時，應在“//”與注釋內容之間增加一個空格。Somecode//

注釋

此處應有空格

規范化編程——標識符命名比較著名的命名規則當推Microsoft公司的“匈牙利”法，該命名規則的主要思想是“在變量和函數名中加入前綴以增進人們對程序的理解”。例如所有的字符變量均以ch為前綴，若是指針變量則追加前綴p。如果一個變量由ppch開頭，則表明它是指向字符指針的指針。“匈牙利”法最大的缺點是煩瑣，例如inti,j,k;floatx,y,z;倘若采用“匈牙利”命名規則，則應當寫成intiI,iJ,ik;//前綴i表示int類型floatfX,fY,fZ;//前綴f表示float類型據考察，沒有一種命名規則可以讓所有的程序員贊同，程序設計教科書一般都不指定命名規則。命名規則對軟件產品而言并不是“成敗悠關”的事。我們不要化太多精力試圖發明世界上最好的命名規則，而應當制定一種令大多數項目成員滿意的命名規則，并在項目中貫徹實施。但是毫無爭議的，“匈牙利”法還是被應用最多的，建議使用。規范化編程——標識符命名規則1：命名盡量使用英文單詞，力求簡單清楚，避免使用引起誤解的詞匯和模糊的縮寫，使人產生誤解。較長的單詞可取單詞的頭幾個字母形成縮寫；如一些單詞有大家公認的縮寫。規范化編程——標識符命名規則2：命名規范必須與所使用的系統風格保持一致，并在同一項目中統一。說明：1）如在UNIX系統，可采用全小寫加下劃線的風格或大小寫混排的方式，但不能使用大小寫與下劃線混排的方式。2）用作特殊標識如標識成員變量或全局變量的m_和g_，其后加上大小寫混排的方式是允許的。規范化編程——標識符命名規則3：常量、宏和模板名采用全大寫的方式，每個單詞間用下劃線分隔。建議4：枚舉類型enum常量應以大寫字母開頭或全部大寫。建議5：命名中若使用了特殊約定或縮寫，則要有注釋說明。說明：應該在源文件的開始之處，對文件中所使用的縮寫或約定，特別是特殊的縮寫，進行必要的注釋說明。規則6：自己特有的命名風格，要自始至終保持一致，不可來回變化。說明：個人的命名風格，在符合所在項目組或產品組的命名規則的前提下，才可使用。（即命名規則中沒有規定到的地方才可有個人命名風格）。規則7：對于變量命名，禁止取單個字符（如i、j、k...），建議除了要有具體含義外，還能表明其變量類型、數據類型等，但i、j、k作局部循環變量是允許的。說明：變量，尤其是局部變量，如果用單個字符表示，很容易敲錯（如i寫成j），而編譯時又檢查不出來，有可能為了這個小小的錯誤而花費大量的查錯時間。規范化編程——可讀性規則1：注意運算符的優先級，并用括號明確表達式的操作順序，避免使用默認優先級。規則2：避免使用“魔數”，用有意義的標識來替代。涉及物理狀態或者含有物理意義的常量，不應直接使用數字，必須用有意義的枚舉或宏來代替。規則3：源程序中關系較為緊密的代碼應盡可能相鄰.說明：便于程序閱讀和查找。建議4：不要使用難懂的技巧性很高的語句，除非很有必要時。說明：高技巧語句不等于高效率的程序，實際上程序的效率關鍵在于算法。規范化編程——可讀性魔數（magicnumber），即在編寫程序時直接在程序中運用數字，而不是采用定義宏或是const變量的方式.規范化編程——可讀性規范化編程——可讀性條件運算符規范化編程——可讀性如下表達式，考慮不周就可能出問題，也較難理解。*stat_poi+++=1;*++stat_poi+=1;應分別改為如下：*stat_poi+=1;stat_poi++;//此二語句相當于“*stat_poi+++=1;”++stat_poi;*stat_poi+=1;//此二語句相當于“*++stat_poi+=1;”規范化編程——其他關于變量和結構、函數和過程的相關編程規范，詳見《神思公司軟件編程規范》文檔。在此，不再贅述。規范化編程——其他編程建議※建議1：使用const提高函數的健壯性。const是constant的縮寫，“恒定不變”的意思。被const修飾的東西都受到強制保護，可以預防意外的變動，能提高程序的健壯性。所以很多C++程序設計書籍建議：“Useconstwheneveryouneed”1）用const修飾函數的參數(輸入參數)2）用const修飾函數的返回值3）const成員函數規范化編程——其他編程建議※建議2：提高程序的效率。程序的時間效率是指運行速度，空間效率是指程序占用內存或者外存的狀況。全局效率是指站在整個系統的角度上考慮的效率，局部效率是指站在模塊或函數角度上考慮的效率規范化編程——其他編程建議關于提高程序效率的六條建議1）不要一味地追求程序的效率，應當在滿足正確性、可靠性、健壯性、可讀性等質量因素的前提下，設法提高程序的效率。2）以提高程序的全局效率為主，提高局部效率為輔。3）在優化程序的效率時，應當先找出限制效率的“瓶頸”，不要在無關緊要之處優化。4）先優化數據結構和算法，再優化執行代碼。5）有時候時間效率和空間效率可能對立，此時應當分析那個更重要，作出適當的折衷。例如多花費一些內存來提高性能。6）不要追求緊湊的代碼，因為緊湊的代碼并不能產生高效的機器碼，返回會影響程序的清晰可讀性。規范化編程——其他編程建議※建議3：其他有益于程序編寫的建議1）當心那些視覺上不易分辨的操作符發生書寫錯誤。