程序設計風格要求總結

排版
1、程序塊要采用縮進風格編寫 ，縮進的空格數為 4 個。 原因說明： 由開發工具自動生成的代碼可能不一致，但如果開發工具可以配置，則應該統一配 置縮進為 4 個空格。
2、縮進或者對齊只能使用空格鍵 ，不可使用 TAB 鍵。說明 ： 使用 TAB 鍵需要設置 TAB 鍵的空格數目是 4 格。
3、相對獨立的程序塊之間，變量說明之后必須加空行。 說明 ： 以下情況應該是用空行分開：
1）函數之間應該用空行分開；
2）變量聲明應盡可能靠近第一次使用處，避免一次性聲明一組沒有馬上使用的變量；
3）用空行將代碼按照邏輯片斷劃分；
4）每個類聲明之后應該加入空格同其他代碼分開。
4、 較長的語句（>80 字符）要分成多行書寫。
1）長表達式要在低優先級操作符處劃分新行，操作符放在新行之首，劃分出的新行 要進行適當的縮進，使排版整齊，語句可讀。
2）若函數或過程中的參數較長，則要進行適當的劃分。
3）循環、判斷等語句中若有較長的表達式或語句，則要進行適應的劃分，長表達式 要在低優先級操作符處劃分新行，操作符放在新行之首。
5、不允許把多個短語句寫在一行中，即一行只寫一條語句。 說明： 一行代碼只做一件事情，如只定義一個變量，或只寫一條語句。這樣的代碼容易閱 讀，并且方便于寫注釋。
6、if、for、do、while、case、switch、default default default 等語句自占一行 等語句自占一行，且 if、for、 do、while 等語句的執行語句部分無論多少都要加括號，等語句的執行語句部分無論多少都要加括號{}。
7、代碼行之內應該留有適當的空格。說明：采用這種松散方式編寫代碼的目的是使代碼更加清晰。
1）關鍵字之后要留空格。象 const、virtual、inline、case 等關鍵字之后至少要留一 個空格， 否則無法辨析關鍵字。象 if、for、while 等關鍵字之后應留一個空格再跟左 括號‘（ ’， 以突出關鍵字。
2）函數名之后不要留空格， 緊跟左括號’(’ ， 以與關鍵字區別。
3）‘( ’ 向后緊跟，‘ )’、‘ ，’、‘ ;’ 向前緊跟， 緊跟處不留空格。
4）值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“ =”、“ +=” “ >=”、“ <=”、“ +”、“ *”、“ %”、“ &&”、“ ||”、“ <<” 、“ ^” 等二元操作符 的前后應當加空格。
5）一元操作符如“ !”、“ ~”、“ ++”、“ –”、“ &”（ 地址運算符） 等前后不加 空格。 7）象“［ ］”、“ .”、“ ->” 這類操作符前后不加空格。

注釋
1、源文件頭部應進行注釋，列出：生成日期、作者、模塊目的/功能等。
2、函數頭部應進行注釋，列出：函數的目的/功能、輸入參數、輸出參數、返回 值等。
3、注釋應該和代碼同時更新 ，不再有用的注釋要刪除。
4、注釋的內容要清楚，不能有二義性。 說明： 錯誤的注釋不但無益反而有害。
5、避免在注釋中使用非常 ：避免在注釋中使用非常用的縮寫或者術語。
6、注釋的主要目的應該是解釋為什么這么做，而不是正在做什么。如果從上下 文不容易看出作者的目的，說明程序的可讀性本身存在比較大的問題 ，應考慮對其重構。
7、避免非必要的注釋
8、注釋的版式 說明：注釋也需要與代碼一樣整齊排版 。
1）注釋應與其描述的代碼相近，對代碼的注釋應放在其上方或右方（對單條語句的注釋）相鄰位置，不可放在下面，如放于上方則需與其上面的代碼用空行隔開。
2）注釋與所描述內容進行同樣的縮排。
3）將注釋與其上面的代碼用空行隔開。
4）變量、常量、宏的注釋應放在其上方相鄰位置或右方。
9、對于所有有物理含義的變量，如果其命名不是充分自注釋的，在聲明 時都必須加以注釋，說明其物理含義。
10、數據結構聲明(包括數組、結構、類、枚舉等)，如果其命名不是充分自注釋，必須加以注釋。對數據結構的注釋應放在其上方相鄰位置 ，不可放在下面；對結構中的每個域的注釋可放在此域的右方。
11、對重要變量的定義需編寫注釋 ，特別是全局變量，更應有較詳細的注釋，包 括對其功能、取值范圍、以及存取時注意事項等的說明 、以及存取時注意事項等的說明。
12、分支語句（條件分支、循環語句等）需編寫注釋。 說明： 這些語句往往是程序實現某一特定功能的關鍵，對于維護人員來說，良好的注釋幫助更好的理解程序，有時甚至優于看設計文檔。
13、 注釋不宜過多 也不能太少，源程序中有效注釋量控制在 20％~30%之間。 說明： 注釋是對代碼的“提示”，而不是文檔，不可喧賓奪主，注釋太多會讓人眼花繚亂。
命名
1、命名盡量使用英文單詞 ：力求簡單清楚 ，避免使用引起誤解的詞匯和模糊的 ，使人產生誤解。 說明： 較短的單詞可通過去掉“元音”形成縮寫；較長的單詞可取單詞的頭幾個字母形成縮寫；一些單詞有大家公認的縮寫。
2、命名規范必須與所使用的系統風格保持一致，并在同一項目中統一 ，并在同一項目中統一。 說明
1）如在 UNIX 系統，可采用全小寫加下劃線的風格或大小寫混排的方式，但不能使 用大小寫與下劃線混排的方式。
2）用作特殊標識如標識成員變量或全局變量的 m_和 g_，其后加上大小寫混排的方 式是允許的。
3、常量、宏和模板名采用全大寫的方式 、宏和模板名采用全大寫的方式，每個單詞間用下劃線分隔。
4、枚舉類型 enum 常量應以大寫字母開頭或全部大寫 enum 常量應以大寫字母開頭或全部大寫。
5、命名中若使用了特殊約定或縮寫，則要有注釋說明。 說明： 應該在源文件的開始之處，對文件中所使用的縮寫或約定，特別是特殊的縮寫，進 行必要的注釋說明。
6、自己特有的命名風格，要自始至終保持一致，不可來回變化。
8、函數名以大寫字母開頭，采用謂-賓結構（動-名），且應反映函數執行什么 操作以及返回什么內容。
可讀性
1、用括號明確表達式的操作順序 ，避免使用默認優先級。
2、不要編寫太復雜、多用途的復合表達式。
3、涉及物理狀態或者含有物理意義的常量 ，避免直接使用數字，必須用有意義的枚舉或常量來代替。
4、禁止使用難以理解，容易產生歧義的語句。

C++專用規范
1、在高警告級別下干凈地編譯。 使用編譯器的最高警告級別。要求干凈的（沒有警告的）構建（build）并理解所有 的警告。通過修改代碼來消除警告，而不是通過降低警告級別來消除。對于明確理解其 含義，確信不會造成任何問題的警告，則可以局部關閉。
2、確保資源為對象所占有，使用顯式的 RAII 和智能指針 RAII 和智能指針。
3、主動使用 const，避免使用宏。 應該盡可能的使用常量而不用變量，另外在定義數值的時候，應該把 const 做為默 認的選項。
4、合理使用組合(composition)和繼承 (composition)。 繼承是 C++中耦合度最強的關系之一。軟件工程的一條重要原則是盡量減少耦合，在 組合和繼承都能均可適用的情況下，應該優先考慮使用組合。組合的意思是將一種類型 以成員變量方式嵌入相關類型中。組合有如下優點：
1）在不影響調用代碼的同時也更靈活。
2）編譯期絕緣性好，編譯時間也能縮短。
3）代碼不可預測程度降低（有些類不適合作為基類）。
5、盡可能局部地聲明變量，這通常是在程序具備了足夠的數據來初始化變量之后， 并緊接著首次使用該變量之前。 例外：
1）有時將變量從循環內提出到循環外是有益的。
2）由于常量不增加狀態，因此本條對常量不適用。
6、盡量用異常來報告錯誤。與錯誤碼相比，要盡量用異常來報告錯誤。對一些無法使用異常的錯誤，或者一些不屬于錯誤的情況，可以用狀態碼（status code，例如：返回碼，errno）來報告。如果不可能或不需要從錯誤中恢復，那么可以使用其它方法，比如正?；蚍钦５亟K止程序。在 C++中，和用錯誤碼來報告錯誤相比，用異常來報告錯誤具有許多明顯的優勢，所有這些都使得編出來的代碼更健壯：
1）程序員不能無視異常：錯誤碼的最糟糕的缺點就是在默認情況下它們會被忽略； 即使是給予錯誤碼微不足道的關注，都必須顯式地編寫代碼，以接受錯誤并做出反應。程序員因為偶然（或因為懶惰）而忘記關注錯誤碼是很平常的事。這使得代碼復查變得更困難。
2）異常會自動傳遞：默認情況下錯誤碼不會跨作用域傳遞；為了把一個低層的錯誤 碼通知高層的調用函數，程序員必須在中間層的代碼中顯式地手工編寫代碼以傳遞 該錯誤。異常會自動地跨作用域傳遞，直到被處理為止。
3）異常處理從主控制流中去除了錯誤處理及恢復：錯誤碼的檢測及處理，一旦要寫的話，就必須夾雜在主控制流中（并使之變得難以理解）。這使得主控制流以及錯誤 處理的代碼都更難以理解和維護。異常處理很自然地把錯誤檢測及恢復移到醒目的 catch 代碼塊中，即它使錯誤處理既醒目，又易于使用，而不是糾纏在主控制流中。

個人編碼模板
1、代碼的可讀性要高
對函數和變量的命名應有意義，注釋的表達應該簡潔而準確。
2、 遵循正確的命名約定
當需要給類、函數和變量命名時，需要遵循以下幾點：
1)、確保特定類名的第一個字母大寫；
2)、使用大小寫分離多個單詞的命名；
3)、大寫常數名，并使用下劃線分離單詞；
4)、確保特定功能和變量名的第一個字母小寫；
5)、注意正確使用縮寫。例如，用max而不用maximum。
3、必要時可使用空格
雖然空格對編譯器是沒有意義的，但是可用于提高代碼的可讀性。。
4、注釋必須易于理解
在每個源文件的頂部，使用/* */的風格來寫多行注釋，在注釋中包括名字，編寫代碼的日期，以及簡明扼要地說明程序的實際用途。單行注釋采用//進行注釋
5、整體的代碼縮進
保證縮進的空格數為4，在縮進和對齊時使用空格鍵，或者使用已經設置好空格數為4的 TAB鍵（未設置的TAB鍵不使用）。

總結

以上是生活随笔為你收集整理的编程风格要求总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。