這是C++信徒的摩西十戒，雖然說的是十戒，實(shí)際上有十四條，但這十四條都值得將其銘刻在顯示器的邊緣，供C++程序員們每日膜拜。我要將其銘刻在我的blog里，銘刻在我的記憶里，直到它們成為我思維的一部分。
第0條：不要拘泥于細(xì)節(jié)（了解哪些東西不應(yīng)該標(biāo)準(zhǔn)化）
·縮進(jìn)：不必規(guī)定如何縮進(jìn)，每個(gè)人遵從一個(gè)自己喜歡的規(guī)則即可。
·行長：今天已經(jīng)沒有太大的必要限制80個(gè)字符了，當(dāng)然，越有利于閱讀越好。
·命名：不要太嚴(yán)苛，除了宏應(yīng)該全部大寫外，別的只要遵從某種大家接受的風(fēng)格即可。常見的風(fēng)格有2種，一種是連字符連接全部小寫的單詞，另一種是單詞首字母大寫。如果需要使用各種第三方庫，基本上很難保持一種風(fēng)格。在一定的范圍內(nèi)保持一致，目標(biāo)是使得閱讀更容易即可。
·注釋：不要規(guī)定注釋的格式。不過，使用doxygen語法的注釋是個(gè)好主意，我一直用doxygen產(chǎn)生文檔。
·匈牙利記法：很高興，我為自己厭惡的東西找到了支持我的同盟軍。在C++語言中借助一點(diǎn)小伎倆來表達(dá)類型是無益的，C++壓根就不需要這些，它只會帶來混亂。
·單入口單出口：在支持異常和確定性析構(gòu)的C++世界，這是多余的。
在這里，旗幟鮮明地反對了兩樣?xùn)|西：匈牙利記法和單入單出原則。
第1條：在高警告級別干凈利落地編譯
把編譯器的警告級別開到，并且能夠悄無聲息地生成結(jié)果。對于那種視警告如無物的人，關(guān)門！放狗！也不要輕易的在源代碼中關(guān)閉編譯器警告。
·對于第三方庫，在包含文件周圍加以屏蔽即可。
·未使用參數(shù)：不提供該參數(shù)名稱即可。
·未使用的變量：插入一個(gè)該變量的表達(dá)式即可。這算是一個(gè)慣用法了，會比較多的用到。
·變量未初始化：初始化。需要通過一個(gè)過程來初始化的例外，即形如：obj; init_obj(obj);
·某些分支沒有return返回值。在這些分支上加入斷言：assert(false);再接一個(gè)return返回值。
·有、無符號不匹配。如果無法避免，預(yù)先寫好強(qiáng)制轉(zhuǎn)換。個(gè)人認(rèn)為，盡量避免無符號數(shù)，即使是處理理論上就沒有符號的數(shù)據(jù)，有符號數(shù)適應(yīng)性更好。幾乎沒有必要使用無符號數(shù)---除了某些位操作。
第2條：使用自動構(gòu)建系統(tǒng)
這個(gè)就是DailyBuild嘛！對一個(gè)團(tuán)隊(duì)項(xiàng)目而言，DailyBuild就是心跳，它應(yīng)該可以通過一個(gè)按鈕或是一條命令就能構(gòu)建出整個(gè)系統(tǒng)。您的心跳正常嗎？這里的關(guān)鍵是：只要一個(gè)操作就能完成所有工作。
第3條：使用版本控制系統(tǒng)
還有那個(gè)團(tuán)隊(duì)沒有使用VCs？如果沒有，“盲人騎瞎馬，夜半臨深池”，真是極好的寫照。
第4條：在代碼審查上投入
很多團(tuán)隊(duì)其實(shí)是沒有有效的代碼審查的。亮出自己的代碼，閱讀別人的代碼，這也是熟悉整個(gè)項(xiàng)目的好方法。把代碼投影在墻上，幾個(gè)人坐下來一起評論也是有效的方法。
第5條：一個(gè)實(shí)體應(yīng)該只有一個(gè)緊湊的職責(zé)
單一職責(zé)原則。這個(gè)原則并不那么容易執(zhí)行，即使是STL這樣的程序庫，也一樣會犯違反該原則的錯(cuò)誤。在這里，舉了兩個(gè)違反這一原則的實(shí)現(xiàn)：realloc和stl 中的basic_string。不過，對于basic_string，我想比起MFC中的CString還是好了不少。在《Exceptional C++ style》中，對basic_string作了剖析，并且得出一個(gè)普遍的原則：盡量將函數(shù)實(shí)現(xiàn)為獨(dú)立的函數(shù)而不是成員函數(shù)。
嘗試用一句話來說明一個(gè)模塊的功能，既不多，也不少。如果無法用這樣的一句話加以概括，那么重新考慮規(guī)劃該模塊的職責(zé)。
第0條：不要拘泥于細(xì)節(jié)（了解哪些東西不應(yīng)該標(biāo)準(zhǔn)化）
·縮進(jìn)：不必規(guī)定如何縮進(jìn)，每個(gè)人遵從一個(gè)自己喜歡的規(guī)則即可。
·行長：今天已經(jīng)沒有太大的必要限制80個(gè)字符了，當(dāng)然，越有利于閱讀越好。
·命名：不要太嚴(yán)苛，除了宏應(yīng)該全部大寫外，別的只要遵從某種大家接受的風(fēng)格即可。常見的風(fēng)格有2種，一種是連字符連接全部小寫的單詞，另一種是單詞首字母大寫。如果需要使用各種第三方庫，基本上很難保持一種風(fēng)格。在一定的范圍內(nèi)保持一致，目標(biāo)是使得閱讀更容易即可。
·注釋：不要規(guī)定注釋的格式。不過，使用doxygen語法的注釋是個(gè)好主意，我一直用doxygen產(chǎn)生文檔。
·匈牙利記法：很高興，我為自己厭惡的東西找到了支持我的同盟軍。在C++語言中借助一點(diǎn)小伎倆來表達(dá)類型是無益的，C++壓根就不需要這些，它只會帶來混亂。
·單入口單出口：在支持異常和確定性析構(gòu)的C++世界，這是多余的。
在這里，旗幟鮮明地反對了兩樣?xùn)|西：匈牙利記法和單入單出原則。
第1條：在高警告級別干凈利落地編譯
把編譯器的警告級別開到，并且能夠悄無聲息地生成結(jié)果。對于那種視警告如無物的人，關(guān)門！放狗！也不要輕易的在源代碼中關(guān)閉編譯器警告。
·對于第三方庫，在包含文件周圍加以屏蔽即可。
·未使用參數(shù)：不提供該參數(shù)名稱即可。
·未使用的變量：插入一個(gè)該變量的表達(dá)式即可。這算是一個(gè)慣用法了，會比較多的用到。
·變量未初始化：初始化。需要通過一個(gè)過程來初始化的例外，即形如：obj; init_obj(obj);
·某些分支沒有return返回值。在這些分支上加入斷言：assert(false);再接一個(gè)return返回值。
·有、無符號不匹配。如果無法避免，預(yù)先寫好強(qiáng)制轉(zhuǎn)換。個(gè)人認(rèn)為，盡量避免無符號數(shù)，即使是處理理論上就沒有符號的數(shù)據(jù)，有符號數(shù)適應(yīng)性更好。幾乎沒有必要使用無符號數(shù)---除了某些位操作。
第2條：使用自動構(gòu)建系統(tǒng)
這個(gè)就是DailyBuild嘛！對一個(gè)團(tuán)隊(duì)項(xiàng)目而言，DailyBuild就是心跳，它應(yīng)該可以通過一個(gè)按鈕或是一條命令就能構(gòu)建出整個(gè)系統(tǒng)。您的心跳正常嗎？這里的關(guān)鍵是：只要一個(gè)操作就能完成所有工作。
第3條：使用版本控制系統(tǒng)
還有那個(gè)團(tuán)隊(duì)沒有使用VCs？如果沒有，“盲人騎瞎馬，夜半臨深池”，真是極好的寫照。
第4條：在代碼審查上投入
很多團(tuán)隊(duì)其實(shí)是沒有有效的代碼審查的。亮出自己的代碼，閱讀別人的代碼，這也是熟悉整個(gè)項(xiàng)目的好方法。把代碼投影在墻上，幾個(gè)人坐下來一起評論也是有效的方法。
第5條：一個(gè)實(shí)體應(yīng)該只有一個(gè)緊湊的職責(zé)
單一職責(zé)原則。這個(gè)原則并不那么容易執(zhí)行，即使是STL這樣的程序庫，也一樣會犯違反該原則的錯(cuò)誤。在這里，舉了兩個(gè)違反這一原則的實(shí)現(xiàn)：realloc和stl 中的basic_string。不過，對于basic_string，我想比起MFC中的CString還是好了不少。在《Exceptional C++ style》中，對basic_string作了剖析，并且得出一個(gè)普遍的原則：盡量將函數(shù)實(shí)現(xiàn)為獨(dú)立的函數(shù)而不是成員函數(shù)。
嘗試用一句話來說明一個(gè)模塊的功能，既不多，也不少。如果無法用這樣的一句話加以概括，那么重新考慮規(guī)劃該模塊的職責(zé)。