C++信徒的摩西十戒

2019-11-17 05:31:17

字體：大中小

供稿：網(wǎng)友

　　這是C++信徒的摩西十戒，雖然說的是十戒，實(shí)際上有十四條，但這十四條都值得將其銘刻在顯示器的邊緣，供C++程序員們每日膜拜。我要將其銘刻在我的blog里，銘刻在我的記憶里，直到它們成為我思維的一部分。

　　第0條：不要拘泥于細(xì)節(jié)（了解哪些東西不應(yīng)該標(biāo)準(zhǔn)化）

　　·縮進(jìn)：不必規(guī)定如何縮進(jìn)，每個(gè)人遵從一個(gè)自己喜歡的規(guī)則即可。

　　·行長(zhǎng)：今天已經(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++壓根就不需要這些，它只會(huì)帶來混亂。

　　·單入口單出口：在支持異常和確定性析構(gòu)的C++世界，這是多余的。

　　在這里，旗幟鮮明地反對(duì)了兩樣?xùn)|西：匈牙利記法和單入單出原則。

　　第1條：在高警告級(jí)別干凈利落地編譯

　　把編譯器的警告級(jí)別開到最大，并且能夠悄無聲息地生成結(jié)果。對(duì)于那種視警告如無物的人，關(guān)門！放狗！也不要輕易的在源代碼中關(guān)閉編譯器警告。

　　·對(duì)于第三方庫，在包含文件四周加以屏蔽即可。

　　·未使用參數(shù)：不提供該參數(shù)名稱即可。

　　·未使用的變量：插入一個(gè)該變量的表達(dá)式即可。這算是一個(gè)慣用法了，會(huì)比較多的用到。

　　·變量未初始化：初始化。需要通過一個(gè)過程來初始化的例外，即形如：obj; init_obj(obj);

　　·某些分支沒有return返回值。在這些分支上加入斷言：assert(false);再接一個(gè)return返回值。

　　·有、無符號(hào)不匹配。假如無法避免，預(yù)先寫好強(qiáng)制轉(zhuǎn)換。個(gè)人認(rèn)為，盡量避免無符號(hào)數(shù)，即使是處理理論上就沒有符號(hào)的數(shù)據(jù)，有符號(hào)數(shù)適應(yīng)性更好。幾乎沒有必要使用無符號(hào)數(shù)---除了某些位操作。

　　第2條：使用自動(dòng)構(gòu)建系統(tǒng)

　　這個(gè)就是DailyBuild嘛！對(duì)一個(gè)團(tuán)隊(duì)項(xiàng)目而言，DailyBuild就是心跳，它應(yīng)該可以通過一個(gè)按鈕或是一條命令就能構(gòu)建出整個(gè)系統(tǒng)。您的心跳正常嗎？這里的要害是：只要一個(gè)操作就能完成所有工作。

　　第3條：使用版本控制系統(tǒng)

　　還有那個(gè)團(tuán)隊(duì)沒有使用vcs？假如沒有，“盲人騎瞎馬，夜半臨深池”，真是極好的寫照。

　　第4條：在代碼審查上投入

　　很多團(tuán)隊(duì)其實(shí)是沒有有效的代碼審查的。亮出自己的代碼，閱讀別人的代碼，這也是熟悉整個(gè)項(xiàng)目的好方法。把代碼投影在墻上，幾個(gè)人坐下來一起評(píng)論也是有效的方法。

　　第5條：一個(gè)實(shí)體應(yīng)該只有一個(gè)緊湊的職責(zé)

　　單一職責(zé)原則。這個(gè)原則并不那么輕易執(zhí)行，即使是STL這樣的程序庫，也一樣會(huì)犯違反該原則的錯(cuò)誤。在這里，舉了兩個(gè)違反這一原則的聞名實(shí)現(xiàn)：realloc和stl 中的basic_string。不過，對(duì)于basic_string，我想比起MFC中的CString還是好了不少。在《Exceptional C++ style》中，對(duì)basic_string作了剖析，并且得出一個(gè)普遍的原則：盡量將函數(shù)實(shí)現(xiàn)為獨(dú)立的函數(shù)而不是成員函數(shù)。

　　嘗試用一句話來說明一個(gè)模塊的功能，既不多，也不少。假如無法用這樣的一句話加以概括，那么重新考慮規(guī)劃該模塊的職責(zé)。第6條：正確、簡(jiǎn)單和清楚第一

　　簡(jiǎn)單的說，堅(jiān)持KISS原則：正確優(yōu)于速度，簡(jiǎn)單優(yōu)于復(fù)雜，清楚優(yōu)于機(jī)巧，安全優(yōu)于不安全。

　　·程序必須為閱讀它的人編寫，只是順便用于機(jī)器執(zhí)行 * 編寫程序應(yīng)該以人為本，計(jì)算機(jī)第二。

　　·計(jì)算機(jī)系統(tǒng)中最便宜、最快速、最可靠的組件都還不存在。

　　·......簡(jiǎn)單設(shè)計(jì)的重要性怎么強(qiáng)調(diào)也不過分。

　　·使一個(gè)正確的程序變快，比使一個(gè)快速的程序正確要輕易的多。

　　·避免使用程序設(shè)計(jì)語言的冷僻特性，應(yīng)該使用最簡(jiǎn)單的有效技術(shù)。

　　·不要毫無節(jié)制地重載運(yùn)算符。

　　·不要濫用匿名變量，合理使用命名變量。當(dāng)然，這不是說連vector().swap(other)這樣的慣用法也要排斥。

　　·重構(gòu)技術(shù)是改善代碼可讀性的有效手段。

　　第7條：編程中應(yīng)知道何時(shí)和如何考慮可伸縮性

　　從字面上來看，這差不多等于外交辭令。答案無非是“適當(dāng)?shù)摹睍r(shí)候“適當(dāng)?shù)亍笨紤]可伸縮性。這非常依靠于軟件工程師的經(jīng)驗(yàn)和知識(shí)。所以，本條目也“適當(dāng)?shù)亍被乇芰四欠N缺乏營(yíng)養(yǎng)的教導(dǎo)，著重討論算法復(fù)雜度的選擇問題。

　　基本上，線性復(fù)雜度可以作為一個(gè)算法是否可選的分界點(diǎn)。值得花費(fèi)精力避免選擇差于線性復(fù)雜度的算法，而不差于線性復(fù)雜度的算法則可以接受。所以，把性能放在嘴邊的兄弟們注重了，你的精力可別放錯(cuò)了地方，高德納言猶在耳：不成熟的優(yōu)化是程序設(shè)計(jì)中的萬惡之源。必要時(shí)，先努力優(yōu)化復(fù)雜度（選擇好的算法----算法無用論者，去面壁！）。

　　順便提一句排序算法，通用排序算法的復(fù)雜度最好是O(NlgN)，但是特定領(lǐng)域完全可以有更好復(fù)雜度的算法。

　　第8條：不要進(jìn)行不成熟的優(yōu)化

　　“不成熟的優(yōu)化是程序設(shè)計(jì)中的萬惡之源” ----高德納引用的這句話這本書中出現(xiàn)了若干次，高德納在他的不朽名著《計(jì)算機(jī)程序設(shè)計(jì)藝術(shù)》中也一再強(qiáng)調(diào)了這一點(diǎn)，還說他以前程序中的許多錯(cuò)誤都是關(guān)于不成熟優(yōu)化的。看來，唯一在誘惑面前沒有墮落的，只有耶穌，即使是大師也無法抗拒。既然如此，建議把下面的話放在電腦桌面上：讓一個(gè)正確的程序更快速，

　　比讓一個(gè)快速的程序正確，要輕易的太多太多。

　　第9條：不要進(jìn)行不成熟的劣化

　　什么是不成熟的劣化呢？典型的有：

　　·在可以通過引用傳遞的時(shí)候，卻定義了通過值傳遞參數(shù)。

　　·在使用前綴++操作符很適合的場(chǎng)合，卻使用后綴版本。

　　·在構(gòu)造函數(shù)中使用賦值操作而不是初始化列表。

　　關(guān)于第一條有一些例外，一般而言，不建議傳遞原生類型的引用（討論前提是傳值的程序語義沒有問題）。關(guān)于第二條，一些很老的C語言的書上有過后綴版本可能比前綴版本更快----當(dāng)然，這只可能針對(duì)原生類型--的說法，忘記它吧，現(xiàn)代編譯器會(huì)輕而易舉的優(yōu)化掉這之間的差異。而對(duì)于用戶定義類型，實(shí)現(xiàn)后綴形式的++和--操作符都意味著效率上的損失。習(xí)慣的力量是巨大的，養(yǎng)成使用前綴版本的習(xí)慣吧。
然而，要區(qū)別不成熟的優(yōu)化和不成熟的劣化之間，需要足夠的練習(xí)和基礎(chǔ)知識(shí)，這些知識(shí)可以從《Effective C++》,《More Effective C++》《Exceptional C++》《More Exceptional C++》中獲得。

　　第10條：盡量減少全局和共享數(shù)據(jù)

　　全局?jǐn)?shù)據(jù)是應(yīng)該努力避免的，它導(dǎo)致兩個(gè)問題：名字污染和遠(yuǎn)程耦合。類的公有靜態(tài)變量只是解決了名字污染問題，并沒有解決遠(yuǎn)程數(shù)據(jù)耦合問題。同樣，Singleton模式也存在遠(yuǎn)程耦合問題。

　　全局?jǐn)?shù)據(jù)通常就意味著共享，共享數(shù)據(jù)則意味著關(guān)系，意味著復(fù)雜性。再多線程中，對(duì)共享數(shù)據(jù)的訪問通常都需要串行化。
關(guān)于變量，一個(gè)比較深刻的看法是：一個(gè)算法使用的變量（命名的和匿名的）越少，就越好。這個(gè)變量包括局部變量。

　　第11條：信息隱藏

　　對(duì)于一個(gè)類，決不要將數(shù)據(jù)公開（數(shù)值聚合的strUCt 例外），也不要返回指向內(nèi)部數(shù)據(jù)成員的指針或引用供外部代碼修改。通過提供抽象，我們將獲得插入不變式檢查的能力。

　　第12條：懂得何時(shí)和如何進(jìn)行并發(fā)性編程

　　這個(gè)問題主要是考慮多線程和多進(jìn)程的編程，我期待著并行程序設(shè)計(jì)進(jìn)入C++的領(lǐng)域。要編寫正確、安全的多線程代碼并不簡(jiǎn)單，非凡是考慮到可移植性時(shí)，更是如此。

　　不過，本條目的題目太大了，很難在一個(gè)條目中描述完整，只能概述幾個(gè)要點(diǎn)：

　　·參考目標(biāo)平臺(tái)文檔，了解該平臺(tái)的同步化原語。

　　·最好將平臺(tái)原語用自己設(shè)計(jì)的抽象包裝起來

　　·確保正在使用的類型在多線程程序中使用是安全的

　　第13條：確保資源為對(duì)象所擁有。使用顯式的RAII和智能指針

　　似乎是在《Imperfact C++》中說過：僅僅因?yàn)橛蠷AII就值得使用C++。C++/CLI也強(qiáng)調(diào)引入確定性析構(gòu)，確定性析構(gòu)正式RAII得以實(shí)現(xiàn)的基礎(chǔ)之一。通過RAII我們能夠得到的遠(yuǎn)遠(yuǎn)超出一般程序員的想象，在討論異常安全代碼時(shí)，將進(jìn)一步見識(shí)RAII的威力。

　　在實(shí)現(xiàn)RAII時(shí)，需要小心復(fù)制構(gòu)造和賦值，編譯器的版本可能并不正確。另外，需要確保資源為對(duì)象所有，不要在一行分配一個(gè)以上的資源。下面的代碼是不安全的：

Fun(shared_ptr<Widget>(new Widget), shared_ptr<Widget>(new Widget));

　　取而代之的正確方法是：

shared_ptr<Widget> sp1(new Widget), sp2(new Widget);
Fun(sp1, sp2);

上一篇：用API函數(shù)實(shí)現(xiàn)串行通訊

下一篇：圖片反色的一段程序