C++編程規(guī)范

用戶評論 (總計12條)

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

相關(guān)圖書

• 影視動畫視聽語言
• 拉薩建筑文化遺產(chǎn)
• 我行我速記單詞
• 我行我速記單詞
• 時裝畫技法
• 歐洲經(jīng)濟一體化背景下的技術(shù)標準化
• 氣象水文網(wǎng)絡(luò)信息資源檢索與利用
• 大學(xué)英語詞匯應(yīng)用900句（四級分冊）
• 我行我速記單詞·英語詞匯6500
• 實用物業(yè)管理學(xué)
• 高職高專英語教學(xué)大綱詞匯用法手冊
• 歐洲的未來
• 高職高專英語應(yīng)用能力考試應(yīng)試對策與模擬測試
• 標準日語會話教程
• 標準日語會話教程·初級（教師手冊）
• 圖案設(shè)計
• 薩繆爾森經(jīng)濟理論研究
• 編排設(shè)計
• 設(shè)計色彩寫生
• 話題英語
• 面向模式的軟件體系結(jié)構(gòu)卷3
• 64位微處理器及其編程
• Linux系統(tǒng)應(yīng)用與開發(fā)教程
• 設(shè)計概論
• 設(shè)計速寫