C++編程規(guī)范

出版時(shí)間：2005-9 出版社：人民郵電出版社作者：(美)薩特亞歷山德萊斯庫
Tag標(biāo)簽：無

內(nèi)容概要

在本書中，兩位知名的C++專家將全球C++團(tuán)體的集體智慧和經(jīng)驗(yàn)?zāi)Y(jié)成一套編程規(guī)范。這些規(guī)范可以作為每一個(gè)開發(fā)團(tuán)隊(duì)制定實(shí)際開發(fā)規(guī)范的基礎(chǔ)，更是每一位C++程序員應(yīng)該遵循的行事準(zhǔn)則。書中對(duì)每一條規(guī)范都給出了精確的描述，并輔以實(shí)例說明；從類型定義到差錯(cuò)處理，都給出了最佳的C++實(shí)踐。即使使用C++多年的程序員也會(huì)從中受益匪淺。 
　　本書適合于各層次C++程序員，也可作為高等院校C++課程的教學(xué)參考書。

圖書封面

圖書標(biāo)簽Tags

無

評(píng)論、評(píng)分、閱讀與下載

還沒讀過(18)
勉強(qiáng)可看(132)
一般般(226)
內(nèi)容豐富(9375)
強(qiáng)力推薦(768)

C++編程規(guī)范 PDF格式下載

用戶評(píng)論 (總計(jì)12條)

　　溫故而知新，重新復(fù)習(xí)一些C++的知識(shí)，有一段時(shí)間，出現(xiàn)了非常多關(guān)于C++編程規(guī)范類型的書籍。這些類型的書籍，很大部分內(nèi)容是相同的，個(gè)人比較喜歡看《C++編程規(guī)范》，100條，條款來自《Effective C++》、《More Effective C++》、《Effective STL》、《Exceptional C++》、《More Exceptional C++》等各類書籍。
　　
　　
　　多年以后重新開始看這本書，又有新的收獲：
　　
　　1、不要拘泥小節(jié)
　　
　　前段時(shí)間進(jìn)行項(xiàng)目開發(fā)，小組內(nèi)的開發(fā)人員可以說都是很優(yōu)秀的開發(fā)人員，大家在一起開發(fā)，我想總希望能有一個(gè)基本的編程規(guī)范，很猶豫對(duì)于編程規(guī)范定義到什么級(jí)別。對(duì)于縮進(jìn)、行的長度、注釋、大括號(hào)的形式大家都有自己習(xí)慣的形式，對(duì)于這些編寫的規(guī)范，說實(shí)話真的沒有太大的必要。不管哪一種形式，只要代碼比較清晰，很快就能習(xí)慣，讀取代碼（Review）都比較容易。對(duì)于函數(shù)名和變量名則需要統(tǒng)一的命名方式，這是大家都比較容易達(dá)成共識(shí)的編程規(guī)范，不要花太多時(shí)間去規(guī)范一些沒有必要的規(guī)則，否則阻力很大，效果很差。
　　
　　
　　
　　2、在高警告級(jí)別進(jìn)行編譯
　　
　　最近一些開發(fā)工作主要是類庫的開發(fā)，API的設(shè)計(jì)，所以對(duì)于代碼的質(zhì)量要求很高，這就要求對(duì)于編譯器的各種警告都非常注意，很多bug的引入就是warning開始，很常見的unsigned int和int的轉(zhuǎn)換比較，unsinged int的--操作、浮點(diǎn)數(shù)的精度問題等。
　　
　　
　　
　　3、代碼審查上的投入
　　
　　項(xiàng)目的開發(fā)很產(chǎn)品的開發(fā)，其中一個(gè)很大的區(qū)別就在于生命周期的長短，項(xiàng)目只要驗(yàn)收了就可以，不一定會(huì)有后續(xù)的項(xiàng)目，但是產(chǎn)品的開發(fā)，生命周期很長（當(dāng)然，因?yàn)楫a(chǎn)品被淘汰另當(dāng)別論），代碼的質(zhì)量就非常的重要，根據(jù)用戶的反饋，產(chǎn)品模塊的優(yōu)化升級(jí)。如果代碼質(zhì)量差，優(yōu)化升級(jí)會(huì)成為一個(gè)很痛苦的過程，在產(chǎn)品的開發(fā)過程中，要在代碼審查中投入。
　　
　　4、正確、簡單和清晰第一
　　
　　上周和同事進(jìn)行XP編程，發(fā)現(xiàn)同事很喜歡直接用調(diào)用函數(shù)并將函數(shù)的返回值作為參數(shù)傳遞，個(gè)人喜歡上非常不喜歡這種優(yōu)化，一是調(diào)試很多時(shí)候無法看到返回值（純虛類的接口）。二代碼的清晰被破壞，可讀性變差。再則我覺得這種優(yōu)化根本沒有必要，都是基本類型的。
　　
　　
　　5、積極使用Const
　　
　　在做API設(shè)計(jì)的時(shí)候，需要考慮API的各種使用情況，需要提供const和非const的版本。
　　
　　
　　6、考慮將虛擬函數(shù)申明為非公用的，將公用函數(shù)申明為非虛擬的
　　
　　在API設(shè)計(jì)中，經(jīng)常會(huì)采用多層設(shè)計(jì)，實(shí)現(xiàn)類的設(shè)計(jì)中引入了虛擬函數(shù)和公用函數(shù)，避免公用函數(shù)被重載。
　　
　　
　　7、廣泛的使用斷言記錄內(nèi)部假設(shè)和不變式
　　
　　越底層，越要采用斷言，避免不要的條件判斷影響性能以及錯(cuò)誤的引入。
　　
　　
　　8、正確的報(bào)告、處理和轉(zhuǎn)換錯(cuò)誤
　　
　　API的設(shè)計(jì)，一定要有這些處理和Log，否則用戶無法知道錯(cuò)誤的原因，導(dǎo)致可用性非常的差。
　　
　　
　　9、顯式定義構(gòu)造函數(shù)、析構(gòu)函數(shù)、拷貝構(gòu)造函數(shù)和復(fù)制函數(shù)。
　　
　　
　　10、還有一點(diǎn)是關(guān)于繼承實(shí)現(xiàn)中的前置條件和后置條件的定義要非常的清晰明確。
　　
　　
　　《C++編程規(guī)范》的很多條例也是根據(jù)OOD的五大原則進(jìn)行設(shè)計(jì)的。
　　
　　
　　
　　1、單一職責(zé)原則（SRP）
　　
　　2、開放-封閉原則
　　
　　3、Liskov替換原則
　　
　　4、依賴倒置原則
　　
　　5、接口隔離原則
　　
　　
　　號(hào)稱是20年集大成之作，羅列了一大堆最佳實(shí)踐的條款
　　有口號(hào)，有說明，有實(shí)作，形式上挺好
　　前面一些談設(shè)計(jì)，組織，策略上的條款是很實(shí)在，后面展開談細(xì)節(jié)，模板，異常，容器，算法之類，就難逃教條主義的嫌疑了，晦澀，模糊，說服力不強(qiáng)
　　中間用的例子有些也不是很清晰貼切
　　光買了書，唉沒時(shí)間看書?。∥译娔XZ差啊，學(xué)得頭都大了??！還好，室友告訴我上獵豹網(wǎng)校，看那個(gè)視頻課程學(xué)。嘿嘿，這是個(gè)簡單容易的辦法！這下不再擔(dān)心買了書，束之高閣了！
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　其實(shí)我想看個(gè)實(shí)踐，別人的方法。
　　副標(biāo)題叫Best Practices，但是Practice很少。
　　這本書的內(nèi)容都缺少實(shí)踐，站著說話不腰疼，對(duì)于我這樣的菜鳥感覺是這樣的。
　　
　　比如這條，比如有個(gè)巨類：
　　CHugeClass
　　{
　　 function0();
　　 function1();
　　 function2();
　　 function3();
　　....
　　 function98();
　　 function99();
　　}
　　使用組合代替繼承（第34條）
　　把上面的類變成：
　　CBigClass
　　{
　　 smallClass0;
　　 smallClass1;
　　 smallClass2;
　　 smallClass3;
　　......
　　 smallClass10;
　　}
　　使用的時(shí)候從huge.func()變成huge.small.func()，但是好像犧牲一下使用上的靈活。
　　
　　誰愿意就這個(gè)問題討論一下。
　　
　　
　　名字起的很有吸引力，其實(shí)內(nèi)容很多章節(jié)講的東西，都是<<effective c++>>里面的，我不知道原版書的文采怎么樣？所以我不好妄加評(píng)論，但這本中文版的譯者的翻譯水平，我真的不敢茍同，翻譯的僵硬，晦澀，缺乏靈活性，估計(jì)就是逐字翻譯的，唉，浪費(fèi)了我?guī)资畨K錢，買了一本多余的書！
　　其實(shí)這本書很雞肋。因?yàn)榇藭菍?duì)一條條的規(guī)范、原則、實(shí)踐等的高度提煉，能力到了自然能理解，能力沒到看完也不一定能理解，此時(shí)你需要類似《Unix編程藝術(shù)》的書，當(dāng)然你仍然需要足夠的實(shí)踐來支持，要不就會(huì)像我一樣在這里說大話！
　　
　　如果你是完美主義者，如果你本來就注重思維訓(xùn)練，那么相信你平時(shí)就已經(jīng)在身體力行這書里的大部分規(guī)范了。但是即使如此，此書還至少有兩個(gè)價(jià)值：1.措辭優(yōu)美，并且大量引經(jīng)據(jù)典，可以找到不少其他優(yōu)秀的書來進(jìn)一步的閱讀；2.讓完美主義者避免掉進(jìn)“過分完美”的陷阱。
　　
　　對(duì)了，這類思維、習(xí)慣方面的話題，并不要求你一定具有C++的知識(shí)，其內(nèi)容一樣適用于其他語言，其他語言的知識(shí)也一樣能助你理解。
　　這本書相當(dāng)適合有一定C++編程經(jīng)驗(yàn)的初級(jí)，中級(jí)程序員閱讀。這本書討論了101個(gè)規(guī)則，每個(gè)規(guī)則都按照，固定的格式（包括條款標(biāo)題，摘要，討論，示例等部分）進(jìn)行說明。這樣的編排方式即清晰又符合我們理解接受的漸進(jìn)過程。
　　
　　也許可以邊看書邊試著做一些回憶，想想自己是否在編程時(shí)候使用或注意到這些規(guī)范。還可以問自己一些問題，例如在我們的設(shè)計(jì)風(fēng)格中是否注意了，”對(duì)一個(gè)函數(shù)之賦予一種職責(zé)“，”正確，簡單和清晰第一，軟件簡單為美（Keep It Simple Software, KISS）“，”優(yōu)先使用線性算法或者盡可能快的算法：例如O(N)“，”盡量減少全局和共享數(shù)據(jù)（會(huì)增加耦合度，從而降低可維護(hù)性，通常還會(huì)降低性能）“等等。
　　
　　我們也可以考慮一下我們的編程風(fēng)格，并問自己: 我們有沒有做到避免使用宏，盡可能局部聲明變量, 總是初始化變量，避免函數(shù)過長，避免嵌套過深，是否做到確保所編寫的每個(gè)頭文件都能夠獨(dú)自進(jìn)行編譯。
　　
　　C++之父Bjarne Stroustrup說過“軟件開發(fā)最重要的一個(gè)方面就是弄清楚自己要構(gòu)建的是什么”，對(duì)于類的設(shè)計(jì)與繼承這一部分也相當(dāng)值得一讀，例如以下條款“用小類代替巨類”，“ 用組合代替繼承”，“避免從并非要設(shè)計(jì)成基類的類中繼承”，“優(yōu)先提供抽象接口”，“共用繼承即可替換性。繼承，不是為了重用，而是為了被重用，Liskov替換原則: Liskov Substitution Principle，共用繼承所建模的必須總是“是一個(gè)is a”，更精確的“其行為象一個(gè) works like a ”關(guān)系：所有基類約定必須滿足這一點(diǎn)?！钡鹊?，也許我們對(duì)這些規(guī)則都了然于胸，但是我們是否時(shí)時(shí)刻刻注意到這些規(guī)則呢，這本書就提供了這樣一個(gè)“小聲音”，提醒我們，在經(jīng)過一段時(shí)間的編程后，我們也許常常會(huì)被一些“壞習(xí)慣”占據(jù)，這個(gè)“小聲音”，也許就是摒除這些“壞習(xí)慣”的利器，
　　
　　也許你和我一樣在編寫C++的時(shí)候會(huì)不自覺地使用了一些不先進(jìn)的C的方式，例如使用數(shù)組，匈牙利標(biāo)法，switch等等，看了這本書后絕對(duì)會(huì)大有啟發(fā)，例如以下的部分書摘：
　　
　　”匈牙利記法：將類型信息并入變量名的記法，是混用了類型不安全語言（特別是C）中的設(shè)施，這在面向?qū)ο笳Z言中是可以存在的，但是有害無益，在泛型編程則更不不行。所以，任何C++編程規(guī)范都不應(yīng)該要求使用匈牙利記法，而在規(guī)范中選擇禁用該記法則是合理的?！?
　　
　　”通過類型分支（type switching）來定制行為既不牢固，容易出錯(cuò)，又不安全，而且是企圖用C++編寫C代碼的明顯標(biāo)志。這是一種很不靈活的技術(shù)，要添加新特性時(shí)必須回過頭對(duì)現(xiàn)有代碼進(jìn)行修改。它還不安全，因?yàn)樘砑有骂愋蜁r(shí)，如果忘記修改所有分支，編譯器也不會(huì)告知。“
　　
　　“不要使用C語言風(fēng)格的數(shù)組，指針運(yùn)算和內(nèi)存管理原語操作實(shí)現(xiàn)數(shù)組抽象。使用vector或者string不僅更輕松，而且還有助于編寫更安全，伸縮性更好的軟件。毋庸置疑，在當(dāng)今軟件中緩沖區(qū)溢出和安全缺陷是罪魁禍?zhǔn)?。固定長度的數(shù)組所帶來的愚蠢限制，即使仍在正確界限內(nèi)，也是軟件開發(fā)人員的一大困擾。”
　　
　　”不要使用C風(fēng)格的強(qiáng)制轉(zhuǎn)換?！?br /> 　　
　　初級(jí)，中級(jí)程序員看了本書后一定會(huì)大有收獲，掌握這些規(guī)范，也許是成長為優(yōu)秀程序員的重要的堅(jiān)實(shí)一步。
　　
　　------- ------
　　本文原始地址：http://hanyionet.blogspot.com/2009/09/blog-post_20.html
　　引用pongba的話：C++中眾多的細(xì)節(jié)雖然在庫設(shè)計(jì)者手里面有其用武之地，但普通程序員則根本無需過多關(guān)注，尤其是沒有實(shí)際動(dòng)機(jī)的。
　　
　　關(guān)注編碼實(shí)踐準(zhǔn)則才是真正需要花時(shí)間掌握的東西!
　　比較輕量級(jí)的一本書。如果你已經(jīng)看過 effective c++ ，exceptional c++系列，那這本書只用翻翻目錄就行了。
　　本評(píng)論轉(zhuǎn)自我的Blog
　　轉(zhuǎn)載必須包含本聲明、保持本文完整。并以超鏈形式注明作者編程隨想和本文原始地址：
　　http://program-think.blogspot.com/2009/01/cxx-coding-standards-101-rules.html
　　
　　全書的101個(gè)條款分布在如下的12部分中，下面來挨個(gè)介紹一下。
　　
　　1、組織與策略
　　這部分其實(shí)不是講C++，而是更偏向于軟件工程方面。如果你是一個(gè)部門或者團(tuán)隊(duì)的主管，要仔細(xì)思考一下：這些條款你的團(tuán)隊(duì)/部門是否都做到了？如果你是一個(gè)C++新手，可以先略過這部分。
　　
　　2、設(shè)計(jì)風(fēng)格
　　這部分講的是通用程序設(shè)計(jì)哲學(xué)，并不限于C++，而是適用于所有的編程語言。如果你對(duì)C++已經(jīng)入門，但是想再上一個(gè)境界，本部分你必須好好領(lǐng)會(huì)。我估計(jì)有十年編程經(jīng)驗(yàn)的老手也未必能夠完全吃透該部分的所有條款。
　　
　　3、編碼風(fēng)格
　　終于開始說到C++語法了！本部分說得都是一些基本的東東，C++新手要好好看看這部分，老手倒未必了。
　　
　　4、函數(shù)與操作符（運(yùn)算符）
　　如果你是從其它語言Java和C轉(zhuǎn)到C++，可能對(duì)操作符重載還不適應(yīng)，需要了解一下這部分。如果你原來是Python程序員，估計(jì)對(duì)操作符重載，應(yīng)該會(huì)比較有親切感。
　　
　　5、類設(shè)計(jì)和繼承
　　最好你已經(jīng)有了一定的OO理論功底，然后再來看這部分，效果會(huì)更好。
　　
　　6、構(gòu)造、析構(gòu)、拷貝
　　這部分讀起來的難度不大。不過有幾個(gè)幾個(gè)細(xì)節(jié)需要注意（即使你已是熟手）。
　　
　　7、名空間和模塊
　　如果你需要從事規(guī)模比較大的C++項(xiàng)目的開發(fā)，那么本部分一定要了解一下。比較大的項(xiàng)目一般都會(huì)涉及到邏輯分割（分名空間）和物力分割（分模塊）。
　　
　　8、模板與范型
　　這部分適合已經(jīng)比較熟悉C++的開發(fā)人員，新手可以先略過。
　　
　　9、錯(cuò)誤處理與異常
　　錯(cuò)誤和異常的處理，是編程領(lǐng)域公認(rèn)的難點(diǎn)。頭幾條是關(guān)于原理性的條款（因此也適用于其它語言），需要深刻領(lǐng)會(huì)；后幾條是關(guān)于C++語法，你如果對(duì)try-catch不熟悉的話要注意看看了（即使是2-3年開發(fā)經(jīng)驗(yàn)的，也有許多不熟悉異常處理）。
　　
　　10、STL容器　11、STL算法
　　如果你是從其它語言（Java、C）轉(zhuǎn)到C++，或者你原先只用MFC，那么估計(jì)你的STL會(huì)有欠缺，好好看看這兩部分吧。
　　
　　12、類型安全
　　如果你是從C轉(zhuǎn)到C++，這部分尤其要注意看一下。里面提到的幾個(gè)條款都是和C的缺點(diǎn)有關(guān)（這么說，C fans看了可別動(dòng)怒?。?。
日特特與
受教了；

C++編程規(guī)范

用戶評(píng)論 (總計(jì)12條)

推薦圖書

相關(guān)圖書