組織和策略問題
＃0 了解哪些東西不應該標準化
注釋不是越多越好，應該注意實用原則，主要用來解釋方法和原理
＃1 在高警告級別下編譯，理解并排除所有的警告
如果引用的第三方庫有警告，可以用自定義的頭文件包含這個庫的頭文件，在自定義頭文件中忽略這些警告。
如：
#pragma warning(push)//保存當前的警告
#pragma warning(disable:4512)
#pragma warning(disable:4180)
#include <boost/lambda/lambda.hpp>//第三方頭文件
#pragma warning(pop)//恢復到之前的警告
＃2 使用自動構建系統
使用單操作的自動化構建
＃3 使用版本控制系統
CVS。不要讓文件長時間登出，確保登入的代碼不會影響構建成功
＃4 在代碼審查上投入
更多的關注有助于提高質量。亮出自己的代碼，閱讀別人的代碼。
設計風格
不成熟的優化是程序涉及中的萬惡之源
＃5 一個實體應該只有一個緊湊的職責
一次只解決一個問題
＃6 正確、簡單和清晰第一
簡單就是美（Keep It Simple Software，KISS）。
使用最簡單的有效技術。
＃7 編程中應該知道何時和如何考慮可伸縮性
集中精力改善算法的O(N)復雜性，而不是進行小型的優化。
要時刻了解算法的實際復雜性
＃8 不要進行不成熟的優化
決不要過早進行優化，再三測試，然后在必要的時候進行優化
讓一個正確的程序更快，比讓一個快速的程序正確，要容易的多。
優化之前應進行度量，度量之前必須確定優化的目標。
＃9不要進行不成熟的劣化
放松自己，輕松編程
引用傳遞代替值傳遞
使用前綴++代替后綴++.
使用初始化列表代替構造函數中賦值
使用抽象和庫
＃10 盡量減少全局和共享數據
共享容易導致沖突，增加耦合度
用通信方式代替數據共享
盡量降低類間的耦合，減少交互
＃11 隱藏信息
不要從任何提供抽象的實體中公開數據
＃12 懂得何時和如何進行并發性編程 （* 我沒多少經驗，難以理解）
避免死鎖，活鎖和惡性競爭條件
＃13 確保資源為對象所擁有，使用顯式的RAII和智能指針
資源獲取即初始化（RAII）
分配資源后立即賦給屬主對象。
永遠不要在一條語句中分配一個以上的資源
當需要配對的獲取/釋放函數調用時，都應該將資源封裝在一個對象中。注意復制構造和賦值操作，以及自身賦值
?
編程風格
＃14 寧要編譯時和連接時錯誤，也不要運行時錯誤
能在編譯時做的事就不要推遲到運行時。
＃15 積極使用const
當知道某個值不會改變時就把它設為const。把const變成定義值時的默認選項
使用mutable
＃16 避免使用宏
只在幾個無法避免的地方使用：
#include 保護符
#ifdef和#if defined
assert實現
＃17 避免使用魔數
使用符號名稱代替它，符號名稱易于理解和維護
使用const,枚舉類型活函數
＃18 盡可能局部地聲明變量
變量的作用域越小越好，生存期越短越好
＃19 總是初始化變量
初始化數組和結構的簡單方法：
ing total[100] = {0};
struct Data
{
int i;
double d;
char szName[10];
};
Data d={0};
注意，volatile型數據不需要程序對其進行初始化
＃20 避免函數過長，避免嵌套過深
＃21 避免跨編譯單元的初始化依賴
保持初始化順序
盡量避免名稱空間級的變量
＃22 盡量減少定義性依賴。避免循環依賴
如果可以用前向聲明就不要#include
只有兩種情況需要某個類的完整定義：
1 需要知道該類的大小
2 需要命名或者調用該類的成員
打破循環的一個方法就是，不要讓高層模塊依賴低層模塊，而是讓兩者都依賴于抽象
＃23 頭文件應該自給自足 （* 一值對什么時候應該包含頭文件很迷惑，好好理解一下＃22和＃23）
應該確保所編寫的每個頭文件都能夠獨自編譯，即當需要用到某個頭文件中的內容時，只需要包含此文件，而不需要包含其他的文件。
模板是在其定義處編譯的，但非獨立名稱或者類型要等到模板實例化時才編譯。
＃24總是編寫內部＃include保護符，決不要編寫外部＃include保護符
//for foo.h
#ifndef FOO_H_INCLUDED_
#define FOO_H_INCLUDED_
//......
#endif
函數與操作符
＃25 正確地選擇通過值，（智能）指針或引用傳遞參數
＃26 保持重載操作符的自然語義
＃27 優先使用算術操作符和賦值操作符的標準形式
定義了a+b 也應該定義a+=b.并且用用+=來定義+.
＃28 優先使用++和－－的標準形式。優先調用前綴形式
應該用前綴形式實現后綴形式
T& T::operator++() //前綴形式
{
//執行遞增
return *this;
}
T T::operator++(int) //后綴形式
{
T old(*this); //保存舊值
++*this;
return old;
}
＃29 考慮重載以避免隱含類型轉換
奧卡姆剃刀原理：如無必要勿增對象。重載會引起臨時對象的創建。
＃30 避免重載&& ||和，
因為內置版本的特殊之處在于：從左到右求值，（對&& ||）短路求值
而函數參數總是會對所有參數進行求值，且求值順序是不確定的。
＃31 不要編寫依賴于函數參數求值順序的代碼
函數參數的求值順序是不確定的
類的設計與繼承
軟件開發最重要的一個方面就是弄清楚自己要構建的是什么。
＃32 弄清所要編寫的是哪種類
值類 模仿內置類型
基類 構成類層次結構
traits類
策略類
異常類
附屬類
＃33 用小類代替巨類
分而治之：小類易于編寫、測試和使用
＃34 用組合代替繼承
繼承是僅次于友元的第二緊密的耦合關系
軟件工程中的一條明智原則就是，盡量減少耦合
通過（智能）指針保存對象，可以減少頭文件依賴性
Pimpl技術：將所有私有成員聚合在一個不透明的指針后面
必須使用繼承的情況：
1 需要改寫虛擬函數
2 需要訪問保護成員
3 需要在基類前構造已使用過的對象，或者在基類之后銷毀此對象（基類比子類先構造，后析構）
4 需要操心虛擬基類
＃35 避免從非必要設計成基類的類中繼承
獨立類和基類的設計有不同的考慮
＃36 優先提供抽象接口
優先采用實現了抽象接口的設計層次結構
＃37 公用繼承即可替換性。繼承，不是為了重用，而是為了被重用
公用繼承描述的是“is-a”或者“works like a”關系
組合描述的是“用...來實現”關系
＃38 實施安全的改寫
＃39 考慮將虛擬函數聲明為非公用的，將公用函數聲明為非虛擬的
＃40 避免提供隱式轉換
隱式轉換構造函數：能夠用一個參數調用且未聲明為explicit的構造函數。
＃41 將數據成員設為私有的、無行為的聚集
＃42 不要公開內部數據
＃43 明智地使用Pimpl
實現編譯器防火墻
class A
{
private:
struct Impl;//存儲所有私有成員
shared_ptr<Impl> pimpl_;
}
＃44 優先編寫非成員非友元函數
＃45 總是一起提供new和delete
＃46 如果提供類專門的new，應該提供所有標準形式（普通、就地和不拋出）
void* operator new(std::size_t);//普通
void* operator new(std::size_t,std::nothrow_t) throw();//不拋出
void* operator new(std::size_t,void*);
定義了一個某種形式的重載會隱藏其他的重載形式
構造、析構與復制
＃47 以同樣的順序定義和初始化成員變量
成員變量初始化順序與在類中聲明的順序一致
＃48 在構造函數中用初始化代替賦值
＃49 避免在構造函數和析構函數中調用虛擬函數
虛擬函數在構造函數和析構函數中并不虛擬
＃50 將基類析構函數設為公用且虛擬的，或者保護且非虛擬的
＃51 析構函數、釋放和交換絕對不能失敗
＃52 一致地進行復制和銷毀
同時定義復制構造函數，復制賦值操作符和析構函數
＃53 顯式地啟用或禁止復制
＃54 避免切片，在基類中考慮用克隆代替復制
＃55 使用賦值的標準形式
＃56 只要可行，就提供不會失敗的swap
名字空間與模塊
模塊：同一個人或小組維護的緊湊的發布單元
＃57 將類型及其非成員函數接口置于同一名字空間中
對于一個類X而言，所有在同一個名字空間中提及X和隨X一起提供的函數邏輯上都是X的一部分，它們形成了X接口的組成部分。
ADL 參數依賴查找
＃58 應該將類型和函數分別置于不同的名字空間中，除非有意想讓它們一起工作
＃59 不要在頭文件中或者＃include之前編寫名字空間using
在頭文件中不要使用using指令或聲明，而應該顯示使用名字空間限定所有名字
不要在＃include之前使用using
＃60 避免在不同的模塊中分配和釋放內存
＃61 不要在頭文件中定義具有鏈接的實體
＃62 不要允許異常跨越模塊邊界傳播
＃63 在模塊的接口中使用具有良好可移至性的類型
不要讓類型出現在波快的外部接口中，除非能確保所有的客戶代碼都能夠正確地理解該類型。
使用客戶代碼能夠理解的最高層抽象。
抽象層越低，可移至性越好。
模板與泛型
＃64 理智地結合靜態多態性和動態多態性
靜態多態性是指模板類和模塊函數
動態多態性是指類的虛擬函數和間接引用
＃65 有意地進行顯示自定義
＃66 不要特化函數模板
＃67 不要無意地編寫不通用的代碼
錯誤處理與異常
問題不在與我們是否會犯錯誤，而在于我們是否會安排編譯器和工具尋找錯誤。
＃68 廣泛地使用斷言記錄內部假設和不變式
一個事件中所含的信息量與該事件發生的概率是成反比的。
不要使用斷言報告運行時錯誤
＃69 建立合理的錯誤處理策略，并嚴格遵守
只在模塊邊界處改變錯誤處理機制
＃70 區別錯誤與非錯誤
前條件
后條件
不變式
＃71 設計和編寫錯誤安全代碼
基本保證：確保出現錯誤時程序會處于有效狀態。
強保證：保證最終狀態要么時最初狀態，要么是所希望的目標狀態。
不會失敗保證：保證操作永遠不會失敗。
＃72 優先使用異常報告錯誤
使用異常而不是錯誤碼
＃73 通過值拋出，通過引用捕獲
＃74 正確地報告、處理和轉換錯誤
＃75 避免使用異常規范
STL容器
＃76 默認使用vector，否則，選擇其他合適的容器
＃77 用vector和string代替數組
＃78 使用vector與非C++API交換數據
&*iter:獲取迭代器引用元素的地址
＃79 在容器中只存儲值和智能指針
在容器中存儲值對象
＃80 用push_back代替其他擴展序列的方式
push_back 是按指數級擴大容量的
＃81 多用范圍操作，少用單元素操作
＃82 使用公認的慣用法真正地壓縮容量，真正地刪除元素
swap：
container<T>(c).swap(c);//去除多余容量的shrink-to-fit慣用法
container<T>().swap(c);//去除全部內容和容量的慣用法
c.erase(remove(c.begin(),c.end(),value),c.end());//刪除元素的慣用法
STL算法
多用算法，少用循環
＃83 使用帶檢查的STL實現
＃84 用算法調用代替手工編寫的循環
采取“處理此范圍”的算法性思維方式，取代“處理每個元素”的循環式思路
使用boost.lambda庫
＃85 使用正確的STL查找算法
查找無序范圍：find/find_if
查找有序范圍：low_bound, upper_bound, equal_range, binary_search.
對有序范圍，p=equal_range(first,last,value);distance(p.first,p.end);比count(first,last,value);更快
＃86 使用正確的STL排序算法
開銷從低到高：partition,stable_partition,nth_element, partial_sort(partial_sort_copy),sort,stable_sort
＃87 使謂詞成為純函數
將謂詞類型的operator()聲明為const
＃88 算法和比較器的參數應多用函數對象少用函數
＃89 正確編寫函數對象
將函數對象設計為復制成本很低的值類型。盡可能從unary_function或binary_function繼承
類型安全
＃90 避免使用類型分支，多使用多態
＃91 依賴類型，而非其表示方式
＃92 避免使用reinterpret_cast
＃93 避免對指針使用static_cast
使用dynamic_cast
＃94 避免強制轉換const
＃95 不要使用C風格的強制轉換
＃96 不要對非POD進行memcpy或者memcmp操作
＃97 不要使用聯合重現解釋表達方式
＃98 不要使用可變長參數
boost.format庫
＃99 不要使用失效對象。不要使用不安全函數
不要使用不安全的C語言遺留函數
＃100 不要多態地處理數組
基類對象的數組和子類對象的數組是完全不同的類型