摘要
只規定需要規定的事情：不要強制施加個人喜好或者過時的做法。 討論
有些問題只是個人喜好，並不影響程式的正確性或者可讀性，所以這些問題不應該出現在程式設計規範中。任何專業程式設計師都可以很容易地閱讀和編寫與其習慣的格式略有不同的**。
應該在每個原始檔乃至每個專案中都使用一致的格式，因為同一段**中要在幾種程式設計風格（
style
）之間換來換去是很不舒服的。但是無需在多個專案或者整個公司範圍內強制實施一致的格式。
下面我們列舉了幾個常見的情況，在這裡重要的不是設定規則，而是與所維護的檔案中已經使用的體例保持一致： l
不要規定縮排多少，應該規定要用縮進來體現**的結構：縮排空格的數量可以遵照個人習慣，但是至少在每個檔案中應該保持一致。 l
l不要在命名方面規定過多
， 應該規定的是使用一致的命名規範
：只有兩點是必需的：（1）永遠不要使用「晦澀的名稱」，即以下劃線開始或者包含雙下劃線的名稱；（2）總是使用形如
only_uppercase_names的全大寫字母表示巨集，不要考慮使用常見的詞或者縮略語作為巨集的名稱（包括常見的模板引數，比如
t和u；像「
#define t anything」這樣的**是極容易混淆的）。此外，應該使用一致的、有意義的名稱，遵循檔案的或者模組的規範。（如果你無法決定自己的命名規範，可以嘗試如下命名規則：類、函式和列舉的名稱形如
likethis，即單詞首字母大寫；變數名形如
likethis，即第乙個單詞首字母小寫，第二個單詞首字母大寫；私有成員變數名形如
likethis_；巨集名稱形如
like_this。） l
不要規定注釋體例（除非需要使用工具從特定的體例中提取出文件），應該編寫有用的注釋：盡可能編寫**而不是寫注釋（比如，見第16條）。不要在注釋中重複寫**語義，這樣很容易產生不一致。應該編寫的是解釋方法和原理的說明性注釋。
最後，不要嘗試強制實施陳舊的規則（見例3和例4），即使它們曾經在一些比較陳舊的程式設計規範中出現過。 示例
例1 括號的位置。以下**在可讀性方面並不存在區別：
void using_k_and_r_style()
[3]
void putting_each_brace_on_its_own_line()
[4]
void or_putting_each_brace_on_its_own_line_indented()
[5]任何乙個專業程式設計師都能夠毫無困難地閱讀
和編寫這些體例中的任何一種。但是應該保持一致：不要隨意地或者以容易混淆作用域巢狀關係的方式放置括號，要盡量遵循每個檔案中已經使用的體例。在本書中，我們對括號位置的選擇主要是為了能夠在編輯允許範圍內得到最佳可讀性。
例2 空格與製表符。有些
團隊禁用製表符（比如
[boostlrg]
），因為不同的編輯器中製表符的設定是不同的，如果使用不當，會將縮排變為「縮出」和「無縮排」。其他同樣受人尊敬的團隊則允許使用製表符，並採取了一些能夠避免其潛在缺陷的規定。這都是合理的，其實只要保持一致即可：如果允許使用製表符，那麼要確保團隊成員維護彼此的**時，不會影響**的清晰和可讀性（見第6條）。如果不允許使用製表符，應該允許編輯器在讀入原始檔時將空格轉換為製表符，使使用者能夠在編輯器中使用製表符，但是在將檔案寫回時，一定要將製表符轉換回空格。
例3 匈牙利記法。將型別資訊併入變數名的記法，是混用了型別不安全語言（特別是c）中的設施，這在物件導向語言中是可以存在的，但是有害無益，在泛型程式設計中則根本不可行。所以，任何c++程式設計規範都不應該要求使用匈牙利記法，而在規範中選擇禁用該記法則是合理的。 例
4 單入口
， 單出口
（ single entry, single exit
， sese
） 。歷史上，有些程式設計規範曾經要求每個函式都只能有乙個出口，也就意味著只能有乙個
return語句。這種要求對於支援異常和析構函式的語言而言已經過時了，在這樣的語言中，函式通常都有多個隱含的出口。取而代之，應該遵循類似於第5條那樣的標準，即直接提倡更簡單的、更短小的函式，這樣的函式本身更易於理解，更容易防錯。
《C 程式設計規範》 不要拘泥於小節
如果人們按照程式設計師程式設計的方式修建房屋，那麼乙隻啄木鳥就能毀滅整個文明。gerald weinberg c 程式設計規範 這本書是對多年的c 經驗的總結，是編寫高質量c 的準則。這本書能給一些初學者帶來質的變化，因為 的規範也是衡量乙個優秀程式設計師的標準。如果你看過這本書的話，就不要繼續看下...
第36條 不要使用 retainCount
本條要點 作者總結 objective c 通過引用計數來管理記憶體 參見第29條 每個物件都有乙個計數器，其值表明還有多少個其他物件想令此物件繼續存活。物件建立好之後，其保留計數大於 0。保留與釋放操作分別會使該計數遞增及遞減。當計數變為 0 時，物件就為系統所 並摧毀了。nsobject 協議中...
0不要拘泥於小節 了解哪些東西不應該標準化
只規定需要規定的事情 不要強制施加個人喜好或者過時的做法 1.有些問題只是個人喜好，並不影響程式的正確性或者可讀性，所以這些問題不應該出現在程式設計規範中 2.應該在每個原始檔乃至每個專案中都使用一致的格式，因為同一段 中要在幾種程式設計風格之間換來換去是非常不舒服的 3.常見不應該標準化的東西 1...