C++編程規(guī)范

前言

盡早進入正軌：以同樣的方式實施同樣的過程。不斷積累慣用法。 將其標準化。如此，你與莎士比亞之間的唯一區(qū)別將只是掌握 慣用法的多少，而非詞匯的多少。 ——Alan Perlis 標準最大的優(yōu)點在于，它提供了如此多樣的選擇。 ——出處尚無定論 我們之所以編寫本書，作為各開發(fā)團隊編程規(guī)范的基礎，有下面兩個主要原因。 編程規(guī)范應該反映業(yè)界最久經(jīng)考驗的經(jīng)驗。它應該包含凝聚了經(jīng)驗和對語言的深刻理解的公認的慣用法。具體而言，編程規(guī)范應該牢固地建立在大量豐富的軟件開發(fā)文獻的基礎之上，把散布在各種來源的規(guī)則、準則和最佳實踐匯集在一起。 不可能存在真空狀態(tài)。通常，如果你不能有意識地制定合理的規(guī)則，那么就會有其他人推行他們自己喜歡的規(guī)則集。這樣產(chǎn)生的編程規(guī)范往往具有各種最不應該出現(xiàn)的屬性。例如，許多這樣的編程規(guī)范都試圖強制盡量少地按C語言的方式使用C++。 許多糟糕的編程規(guī)范都是由一些沒有很好地理解語言、沒有很好地理解軟件開發(fā)或者試圖標準化過多東西的人制定的。糟糕的編程規(guī)范會很快喪失可信度，如果程序員不喜歡或者不同意其中一些糟糕的準則，那么即使規(guī)范中有一些合理的準則，也可能被不抱幻想的程序員所忽略，這還是最好的情況，最壞的情況下，糟糕的標準可能真會被強制執(zhí)行。 如何使用本書 三思而行。應該遵循好的準則，但是不要盲從。在本書的各準則中，請注意“例外情況”部分闡明了該準則可能不適用的不太常見的情況。任何準則，無論如何正確（當然，我們自認為本書中的準則是正確的），都不能代替自己的思考。 每個開發(fā)團隊都應該制定自己的標準，制定標準的時候都應該盡職盡責。這項工作是整個團隊的事情。如果你是團隊負責人，應該讓團隊成員都參與制定標準。人們當然更愿意遵守“自己的”標準，而非別人強加的一堆規(guī)矩。 編寫本書的目的是為各開發(fā)團隊提供編程規(guī)范的基礎和參考。它并不是要成為終極編程規(guī)范，因為不同的團隊會有適合特定群體或者特定任務的更多準則，應該大膽地將這些準則加入本書的條款中。但是我們希望本書能夠通過記載和引用廣泛接受的、權威的、幾乎可以通用的（“例外情況”指出的除外）實踐經(jīng)驗，減少讀者制定或重新制定自己的編程規(guī)范的工作量，從而幫助提高讀者所用編程規(guī)范的質(zhì)量和一致性。 讓團隊人員閱讀這些準則及其原理闡釋（也就是本書全文，根據(jù)需要還包括所選條款引用的其他書籍和論文），共同決定是否有團隊根本無法接受的內(nèi)容（比如，由于某些項目特殊的情況），然后實踐其余規(guī)范。一旦采納，如果未與整個團隊協(xié)商，任何人不得違反團隊編程規(guī)范。 最后，團隊還需定期復查這些準則，加入實際應用中得出的經(jīng)驗和反饋。

內(nèi)容概要

　　在本書中，兩位知名的C++專家將全球C++界20年的集體智慧和經(jīng)驗凝結成一套編程規(guī)范。這些規(guī)范可以作為每一個開發(fā)團隊制定實際開發(fā)規(guī)范的基礎，更是每一位C++程序員應該遵循的行事準則。書中對每一條規(guī)范都給出了精確的描述，并輔以實例說明；從類型定義到錯誤處理，都給出了最佳的C++實踐，即使使用C++多年的程序員也會從本書中受益匪淺。　　本書適合于各層次C++程序員使用，也可作為高等院校C++課程的教學參考書。

作者簡介

作者：（加拿大）薩特（Herb Sutter） （羅馬）亞歷山德雷斯庫（Andrei Alexandrescu） 譯者：劉基誠薩特，（Herb Sutter） 曾任ISO C++標準委員會主席，是C++ Users Journal雜志特邀編輯和專欄作家。他目前在微軟公司領導.NET環(huán)境下C++語言擴展的設計工作。除本書外，他還撰寫了三本廣受贊譽的圖書：Exceptional C++ Style、Exceptional C++和More Exceptional C++。前者中譯本也由人民郵電出版社出版。亞歷山德雷斯庫(Andrei Alexandrescu)世界頂尖的C++專家，C++ Users Journal雜志的專欄作家，他的Modem C++ Design一書曾榮獲2001年最佳C++圖書稱號，所開發(fā)的Loki已經(jīng)成為最負盛名的C++程序庫之一。

書籍目錄

組織和策略問題　  第0條　不要拘泥于小節(jié)(又名：了解哪些東西不應該標準化)　  第1條　在高警告級別干凈利落地進行編譯　  第2條　使用自動構建系統(tǒng)　  第3條　使用版本控制系統(tǒng)　  第4條　做代碼審查　9設計風格　  第5條　一個實體應該只有一個緊湊的職責　  第6條　正確、簡單和清晰  第一　  第7條　編程中應知道何時和如何考慮可伸縮性  第8條　不要進行不成熟的優(yōu)化　  第9條　不要進行不成熟的劣化　  第10條　盡量減少全局和共享數(shù)據(jù)　  第11條　隱藏信息　  第12條　懂得何時和如何進行并發(fā)性編程　  第13條　確保資源為對象所擁有。使用顯式的RAII和智能指針　編程風格　  第14條　寧要編譯時和連接時錯誤，也不要運行時錯誤　  第15條　積極使用const　  第16條　避免使用宏　  第17條　避免使用“魔數(shù)”　  第18條　盡可能局部地聲明變量　  第19條　總是初始化變量　  第20條　避免函數(shù)過長，避免嵌套過深　  第21條　避免跨編譯單元的初始化依賴　  第22條　盡量減少定義性依賴。避免循環(huán)依賴　  第23條　頭文件應該自給自足　  第24條　總是編寫內(nèi)部#include保護符，決不要編寫外部#include保護符　函數(shù)與操作符　  第25條　正確地選擇通過值、(智能)指針或者引用傳遞參數(shù)　  第26條　保持重載操作符的自然語義　  第27條　優(yōu)先使用算術操作符和賦值操作符的標準形式　  第28條　優(yōu)先使用++和--的標準形式。優(yōu)先調(diào)用前綴形式　  第29條　考慮重載以避免隱含類型轉換　  第30條　避免重載&&、||或　,(逗號)　  第31條　不要編寫依賴于函數(shù)參數(shù)求值順序的代碼　類的設計與繼承　  第32條　弄清所要編寫的是哪種類　  第33條　用小類代替巨類　  第34條　用組合代替繼承　  第35條　避免從并非要設計成基類的類中繼承　  第36條　優(yōu)先提供抽象接口　  第37條　公用繼承即可替換性。繼承，不是為了重用，而是為了被重用　  第38條　實施安全的覆蓋　  第39條　考慮將虛擬函數(shù)聲明為非公用的，將公用函數(shù)聲明為非虛擬的　  第40條　要避免提供隱式轉換　  第41條　將數(shù)據(jù)成員設為私有的，無行為的聚集(C語言形式的struct)除外　  第42條　不要公開內(nèi)部數(shù)據(jù)　  第43條　明智地使用Pimpl　  第44條　優(yōu)先編寫非成員非友元函數(shù)　  第45條　總是一起提供new和delete　  第46條　如果提供類專門的new，應該提供所有標準形式(普通、就地和不拋出)　構造、析構與復制　  第47條　以同樣的順序定義和初始化成員變量　  第48條　在構造函數(shù)中用初始化代替賦值　  第49條　避免在構造函數(shù)和析構函數(shù)中調(diào)用虛擬函數(shù)　  第50條　將基類析構函數(shù)設為公用且虛擬的，或者保護且非虛擬的　  第51條　析構函數(shù)、釋放和交換絕對不能失敗　  第52條　一致地進行復制和銷毀　  第53條　顯式地啟用或者禁止復制  第54條　避免切片。在基類中考慮用克隆代替復制　  第55條　使用賦值的標準形式　  第56條　只要可行，就提供不會失敗的swap(而且要正確地提供)　名字空間與模塊　模板與泛型　錯誤處理與異?！TL：容器　STL：算法　類型安全　參考文獻　摘要匯總　索引　

章節(jié)摘錄

插圖：外部加鎖：調(diào)用者負責加鎖。在這種選擇下，由使用對象的代碼負責了解是否跨線程共享了對象，如果是，還要負責串行化所有對該對象的使用。例如，字符串類型通常使用外部加鎖（或者不變性，見第三種選擇）。內(nèi)部加鎖：每個對象將所有對自己的訪問串行化，通常采用為每個公用成員函數(shù)加鎖的方法來實現(xiàn)，這樣調(diào)用者就可以不用串行化對象的使用了。例如，生產(chǎn)者／消費者隊列通常使用內(nèi)部加鎖，因為它們存在的目的就是被跨線程共享，而且它們的接口就是為了在單獨的成員函數(shù)調(diào)用（Push，Pop）期間能夠進行適當?shù)膶哟渭渔i而設計的。更一般的情況下，需要注意，只有在知道了以下兩件事情之后這個選項才適用。第一，必須事先知道該類型的對象幾乎總是要被跨線程共享的，否則到頭來只不過進行了無效加鎖。請注意大多數(shù)類型都不會遇到這種情況，即使是在多線程處理分量很重的程序中，大多數(shù)對象也不會被跨線程共享（這是好現(xiàn)象，見第10條）。第二，必須事先知道成員函數(shù)級加鎖的粒度是合適的，而且能滿足大多數(shù)調(diào)用者的需要。具體而言，類型接口的設計應該有利于粗粒度的、自給自足的操作。如果調(diào)用者總是需要對多個而不是一個操作加鎖，那么就不能滿足需要了，只能通過增加更多的（外部）鎖，將單獨加鎖的函數(shù)組裝成一個更大規(guī)模的已加鎖工作單位。例如一個容器類型，如果它返回一個迭代器，則迭代器可能在用到之前就失效了；如果它提供find之類的能返回正確答案的成員算法，那么答案可能在用到之前就出錯了；如果它的用戶想要編寫這樣的代碼：if（c,empty（））c.push-back（x）；，同樣會出現(xiàn)問題。（更多的例子，參閱[Sutter02]。）在這些情況下，調(diào)用者需要進行外部加鎖，以獲得生存期能夠跨越多個單獨成員函數(shù)調(diào)用的鎖，這樣一來每個成員函數(shù)的內(nèi)部加鎖就毫無用武之地了。

編輯推薦

《C++編程規(guī)范:101條規(guī)則、準則與最佳實踐》：良好的編程規(guī)范可以改善軟件質(zhì)量，縮短上市時間，提升團隊效率，簡化維護工作。在《C++編程規(guī)范:101條規(guī)則、準則與最佳實踐》中，兩位全世界最受尊敬的c++專家將全球c++社區(qū)的集體智慧和經(jīng)驗凝結成一整套編程規(guī)范。這些規(guī)范可以作為每一個開發(fā)團隊制定實際開發(fā)規(guī)范的基礎，更是每一位c++程序員應該遵循的行事準則。《C++編程規(guī)范:101條規(guī)則、準則與最佳實踐》涵蓋了c++程序設計的每一個方面，包括設計和編碼風格、函數(shù)、操作符、類的設計、繼承、構造與析構、賦值、名字空間、模塊、模板、泛型、異常、stl容器和算法等。書中對每一條規(guī)范都給出了言簡意賅的敘述，并輔以實例說明；另外還給出了從類型定義到錯誤處理等方面的大量c++ 最佳實踐，包括許多最新總結和標準化的技術，即使使用c++多年的程序員也會從中受益匪淺。通過閱讀《C++編程規(guī)范:101條規(guī)則、準則與最佳實踐》，可以找到以下問題的答案哪些東西值得標?準化?哪些東西不值得標準化?使代碼可擴展的最佳方法是什么?合理的錯誤處理策略有哪些要素?如何(和為什么要)避免不必要的初始化、循環(huán)依賴和定義依賴?何時應該(以及如何)同時使用靜態(tài)和動態(tài)的多態(tài)性?如何實踐“安全的”改寫?何可時該提供不會失敗的交換?為什么要阻止異常跨越模塊邊界傳播7如何阻止?為什么不應該在頭文件中寫名字空問聲明或指令?為什么應該使用STL vector和string代替數(shù)組?如何選擇正確的STL搜索算法?為了保證代碼的類型安全，應該遵從哪些規(guī)則?C++界20年集大成之作兩位世界頂級專家聯(lián)袂巨獻適合所有層次C++程序員

圖書封面

圖書標簽Tags

無

評論、評分、閱讀與下載

---

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

---