這是C++信徒的摩西十戒，雖然說的是十戒，實際上有十四條，但這十四條都值得將其銘刻在顯示器的邊緣，供C++程序員們每日膜拜。我要將其銘刻在我的blog裡，銘刻在我的記憶裡，直到它們成為我思維的一部分。
第0條：不要拘泥於細節（了解哪些東西不應該標准化）
·縮進：不必規定如何縮進，每個人遵從一個自己喜歡的規則即可。
·行長：今天已經沒有太大的必要限制80個字符了，當然，越有利於閱讀越好。
·命名：不要太嚴苛，除了宏應該全部大寫外，別的只要遵從某種大家接受的風格即可。常見的風格有2種，一種是連字符連接全部小寫的單詞，另一種是單詞首字母大寫。如果需要使用各種第三方庫，基本上很難保持一種風格。在一定的范圍內保持一致，目標是使得閱讀更容易即可。
·注釋：不要規定注釋的格式。不過，使用doxygen語法的注釋是個好主意，我一直用doxygen產生文檔。
·匈牙利記法：很高興，我為自己厭惡的東西找到了支持我的同盟軍。在C++語言中借助一點小伎倆來表達類型是無益的，C++壓根就不需要這些，它只會帶來混亂。
·單入口單出口：在支持異常和確定性析構的C++世界，這是多余的。
在這裡，旗幟鮮明地反對了兩樣東西：匈牙利記法和單入單出原則。
第1條：在高警告級別干淨利落地編譯
把編譯器的警告級別開到最大，並且能夠悄無聲息地生成結果。對於那種視警告如無物的人，關門！放狗！也不要輕易的在源代碼中關閉編譯器警告。
·對於第三方庫，在包含文件周圍加以屏蔽即可。
·未使用參數：不提供該參數名稱即可。
·未使用的變量：插入一個該變量的表達式即可。這算是一個慣用法了，會比較多的用到。
·變量未初始化：初始化。需要通過一個過程來初始化的例外，即形如：obj; init_obj(obj);
·某些分支沒有return返回值。在這些分支上加入斷言：assert(false);再接一個return返回值。
·有、無符號不匹配。如果無法避免，預先寫好強制轉換。個人認為，盡量避免無符號數，即使是處理理論上就沒有符號的數據，有符號數適應性更好。幾乎沒有必要使用無符號數---除了某些位操作。
第2條：使用自動構建系統
這個就是DailyBuild嘛！對一個團隊項目而言，DailyBuild就是心跳，它應該可以通過一個按鈕或是一條命令就能構建出整個系統。您的心跳正常嗎？這裡的關鍵是：只要一個操作就能完成所有工作。
第3條：使用版本控制系統
還有那個團隊沒有使用vcs？如果沒有，“盲人騎瞎馬，夜半臨深池”，真是極好的寫照。
第4條：在代碼審查上投入
很多團隊其實是沒有有效的代碼審查的。亮出自己的代碼，閱讀別人的代碼，這也是熟悉整個項目的好方法。把代碼投影在牆上，幾個人坐下來一起評論也是有效的方法。
第5條：一個實體應該只有一個緊湊的職責
單一職責原則。這個原則並不那麼容易執行，即使是STL這樣的程序庫，也一樣會犯違反該原則的錯誤。在這裡，舉了兩個違反這一原則的著名實現：realloc和stl 中的basic_string。不過，對於basic_string，我想比起MFC中的CString還是好了不少。在《Exceptional C++ style》中，對basic_string作了剖析，並且得出一個普遍的原則：盡量將函數實現為獨立的函數而不是成員函數。
嘗試用一句話來說明一個模塊的功能，既不多，也不少。如果無法用這樣的一句話加以概括，那麼重新考慮規劃該模塊的職責。
第6條：正確、簡單和清晰第一
簡單的說，堅持KISS原則：正確優於速度，簡單優於復雜，清晰優於機巧，安全優於不安全。
·程序必須為閱讀它的人編寫，只是順便用於機器執行 * 編寫程序應該以人為本，計算機第二。
·計算機系統中最便宜、最快速、最可靠的組件都還不存在。
·......簡單設計的重要性怎麼強調也不過分。
·使一個正確的程序變快，比使一個快速的程序正確要容易的多。
·避免使用程序設計語言的冷僻特性，應該使用最簡單的有效技術。
·不要毫無節制地重載運算符。
·不要濫用匿名變量，合理使用命名變量。當然，這不是說連vector().swap(other)這樣的慣用法也要排斥。
·重構技術是改善代碼可讀性的有效手段。
第7條：編程中應知道何時和如何考慮可伸縮性
從字面上來看，這差不多等於外交辭令。答案無非是“適當的”時候“適當地”考慮可伸縮性。這非常依賴於軟件工程師的經驗和知識。所以，本條目也“適當地”回避了那種缺乏營養的教導，著重討論算法復雜度的選擇問題。
基本上，線性復雜度可以作為一個算法是否可選的分界點。值得花費精力避免選擇差於線性復雜度的算法，而不差於線性復雜度的算法則可以接受。所以，把性能放在嘴邊的兄弟們注意了，你的精力可別放錯了地方，高德納言猶在耳：不成熟的優化是程序設計中的萬惡之源。必要時，先努力優化復雜度（選擇好的算法----算法無用論者，去面壁！）。
順便提一句排序算法，通用排序算法的復雜度最好是O(NlgN)，但是特定領域完全可以有更好復雜度的算法。
第8條：不要進行不成熟的優化
“不成熟的優化是程序設計中的萬惡之源” ----高德納引用的這句話這本書中出現了若干次，高德納在他的不朽名著《計算機程序設計藝術》中也一再強調了這一點，還說他以前程序中的許多錯誤都是關於不成熟優化的。看來，唯一在誘惑面前沒有墮落的，只有耶稣，即使是大師也無法抗拒。既然如此，建議把下面的話放在電腦桌面上： 讓一個正確的程序更快速，
比讓一個快速的程序正確，要容易的太多太多。
第9條：不要進行不成熟的劣化
什麼是不成熟的劣化呢？典型的有：
·在可以通過引用傳遞的時候，卻定義了通過值傳遞參數。
·在使用前綴++操作符很適合的場合，卻使用後綴版本。
·在構造函數中使用賦值操作而不是初始化列表。
關於第一條有一些例外，一般而言，不建議傳遞原生類型的引用（討論前提是傳值的程序語義沒有問題）。關於第二條，一些很老的C語言的書上有過後綴版本可能比前綴版本更快----當然，這只可能針對原生類型--的說法，忘記它吧，現代編譯器會輕而易舉的優化掉這之間的差異。而對於用戶定義類型，實現後綴形式的++和--操作符都意味著效率上的損失。習慣的力量是巨大的，養成使用前綴版本的習慣吧。
然而，要區別不成熟的優化和不成熟的劣化之間，需要足夠的訓練和基礎知識，這些知識可以從《Effective C++》,《More Effective C++》《Exceptional C++》《More Exceptional C++》中獲得。
第10條：盡量減少全局和共享數據
全局數據是應該努力避免的，它導致兩個問題：名字污染和遠程耦合。類的公有靜態變量只是解決了名字污染問題，並沒有解決遠程數據耦合問題。同樣，Singleton模式也存在遠程耦合問題。
全局數據通常就意味著共享，共享數據則意味著關系，意味著復雜性。再多線程中，對共享數據的訪問通常都需要串行化。
關於變量，一個比較深刻的看法是：一個算法使用的變量（命名的和匿名的）越少，就越好。這個變量包括局部變量。
第11條：信息隱藏
對於一個類，決不要將數據公開（數值聚合的struct 例外），也不要返回指向內部數據成員的指針或引用供外部代碼修改。通過提供抽象，我們將獲得插入不變式檢查的能力。
第12條：懂得何時和如何進行並發性編程
這個問題主要是考慮多線程和多進程的編程，我期待著並行程序設計進入C++的領域。要編寫正確、安全的多線程代碼並不簡單，特別是考慮到可移植性時，更是如此。
不過，本條目的題目太大了，很難在一個條目中描述完整，只能概述幾個要點：
·參考目標平台文檔，了解該平台的同步化原語。
·最好將平台原語用自己設計的抽象包裝起來
·確保正在使用的類型在多線程程序中使用是安全的
第13條：確保資源為對象所擁有。使用顯式的RAII和智能指針
好像是在《Imperfact C++》中說過：僅僅因為有RAII就值得使用C++。C++/CLI也強調引入確定性析構，確定性析構正式RAII得以實現的基礎之一。通過RAII我們能夠得到的遠遠超出一般程序員的想象，在討論異常安全代碼時，將進一步見識RAII的威力。
在實現RAII時，需要小心復制構造和賦值，編譯器的版本可能並不正確。另外，需要確保資源為對象所有，不要在一行分配一個以上的資源。下面的代碼是不安全的：
Fun(shared_ptr<Widget>(new Widget), shared_ptr<Widget>(new Widget));
取而代之的正確方法是：
shared_ptr<Widget> sp1(new Widget), sp2(new Widget);
Fun(sp1, sp2);
