《C++程式設計規範：101條規則、準則與最佳實踐》——第一章組織和政策問題1.1不要拘泥于小節 （又名：了解哪些東西不應該标準化）

本節書摘來自異步社群出版社《c++程式設計規範：101條規則、準則與最佳實踐》一書中的第1章，第1.1節，作者：【加】herb sutter , 【羅】andrei，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

c++程式設計規範：101條規則、準則與最佳實踐

如果人們按照程式員程式設計的方式修建房屋，

那麼一隻啄木鳥就能毀滅整個文明。

——gerald weinberg[1]

為了遵從c和c++的偉大傳統，我們從0開始編号。首要的指導原則，也就是第0條，闡明了我們認為對程式設計規範而言最為基本的建議。

接下來，這個導論性部分的其他條款将主要講述幾個精心選擇的基本問題，這些問題大多數與代碼本身并沒有直接關系，它們讨論的是編寫堅實代碼所必需的工具和技術。

本部分中我們選出的最有價值條款是第0條：“不要拘泥于小節[2]”（又名：“了解哪些東西不應該标準化”）。

1.1不要拘泥于小節 （又名：了解哪些東西不應該标準化）

摘要

隻規定需要規定的事情：不要強制施加個人喜好或者過時的做法。

讨論

有些問題隻是個人喜好，并不影響程式的正确性或者可讀性，是以這些問題不應該出現在程式設計規範中。任何專業程式員都可以很容易地閱讀和編寫與其習慣的格式略有不同的代碼。

應該在每個源檔案乃至每個項目中都使用一緻的格式，因為同一段代碼中要在幾種程式設計風格（style）之間換來換去是很不舒服的。但是無需在多個項目或者整個公司範圍内強制實施一緻的格式。

下面列舉了幾種常見的情況，在這裡重要的不是設定規則，而是與所維護的檔案中已經使用的體例保持一緻。

不要規定縮進多少，應該規定要用縮進來展現代碼的結構。縮進空格的數量可以遵照個人習慣，但是至少在每個檔案中應該保持一緻。

不要強制行的具體長度，應該保證代碼行的長度有利于閱讀。可以遵照個人習慣來決定行長，但是不要過長。研究表明，文字長度不超過10個單詞最利于閱讀。

不要在命名方面規定過多，應該規定的是使用一緻的命名規範。隻有兩點是必需的：（1）永遠不要使用“晦澀的名稱”，即以下劃線開始或者包含雙下劃線的名稱；（2）總是使用形如only_uppercase_names的全大寫字母表示宏，不要考慮使用常見的詞或者縮略語作為宏的名稱（包括常見的模闆參數，比如t和u；像#define t anything這樣的代碼是極容易混淆的）。此外，應該使用一緻的、有意義的名稱，遵循檔案的或者子產品的規範。（如果你無法決定自己的命名規範，可以嘗試如下命名規則：類、函數和枚舉的名稱形如likethis，即單詞首字母大寫；變量名形如likethis，即第一個單詞首字母小寫，第二個單詞首字母大寫；私有成員變量名形如likethis_；宏名稱形如like_this。）

不要規定注釋風格（除非需要使用工具從特定的體例中提取出文檔），應該編寫有用的注釋。盡可能編寫代碼而不是寫注釋（比如，見第16條）。不要在注釋中重複寫代碼語義，這樣很容易産生不一緻。應該編寫的是解釋方法和原理的說明性注釋。

最後，不要嘗試強制實施過時的規則（見例3和例4），即使它們曾經在一些比較陳舊的程式設計規範中出現過。

示例

例1　大括号的位置。以下代碼在可讀性方面并不存在差別：