永遠不要用#include包含不必要的頭文件
如果只需要流的前置聲明，應該優先使用#include<iosfwd>
只需要前置聲明時，絕不要用#include包含相應的頭文件。
如果使用聚合關系就已經足夠，就不要使用繼承。
要避免使用內聯或者復雜的調整方法，除非通過性能分析證明這確實是必要的。
正確使用名字空間。如果將一個類放入名字空間，那么同時要保證將這個類的所有輔助函數和運算符函數也放入相同的名字空間。否則，你將在代碼中發現奇怪的結果。
要理解這五種不同類型的內存，了解他們為什么是不同的，以及他們各自的行為又是怎么樣：棧（自動變量）、自由存儲（new/delete）、堆（malloc/free）、全局（靜態變量、全局變量、文件作用域變量等）、常量數據（字符串常量等）。
優先使用自由存儲（new/delete），避免使用堆（malloc/free）。
對于“堆”和“自由存儲”進行區分，這一點很重要，因為在C++標準中有意避開了這兩種類型的內存是不是相關的這個問題。例如，當通過：：operator delete()函數來釋放內存時，在C++標準的18.4.1.1中，最后一項是這樣的：
“ 在C++標準中并沒有規定，在哪些情況下，在通過operator delete回收的存儲空間中，有一部分或者全部的控件可以再隨后調用operator new或者calloc，malloc以及realloc等函數時被重新分配，這些函數的聲明時在<cstdlib>中。”
而且，在C++標準中也沒有規定，new/delete是否需要通過malloc/free來實現。不過，在C++標準20.4.6節的第3段和第4段中規定了，malloc/free一定不能使用new/delete來實現：“calloc、malloc和realloc函數不會通過調用::operator new()來分配存儲空間。函數free（）不會通過調用::operator delete() 來釋放內存。”
如果在類中定義了new和delete中的任意一個運算符函數，那么一定要同時定義另外一個。
通常應該顯式地將函數operator new ()和operator delete()聲明為靜態函數。他們永遠都不能使非靜態成員函數。
永遠都不要通過多態的方式處理數組。
優先選擇使用vector或者deque，而不是數組。
在編寫拷貝賦值運算符函數時，永遠都不要指望能夠通過對自我賦值進行檢測來保證函數的正確性；應該在拷貝賦值運算符函數中使用“創建臨時對象并進行交換”的慣用法，這種方法不僅是異常安全的，而且在處理自我賦值時也是安全的。
可以將自我賦值檢測作為一種優化手段，以避免不必要的工作，這是正確地做法。
不僅要避免編寫類型轉換運算符函數，而且還要避免編寫隱式的構造函數。
盡量編寫異常安全的代碼。在編寫代碼時應該始終遵循：即使在出現異常時，資源仍然能夠被正確地釋放，并且數據也總是處于一致的狀態。
避免使用語言中那些不常用的特性，而應該使用最簡單并且有效的技術。
拷貝初始化過程絕不是賦值過程，因此在初始化中永遠都不會調用函數T::operator=()。是的，我知道在初始化語句中有一個“=”符合，但不要被它迷惑。它只是從C語言中沿用過來的一種語法，并不代表賦值運算。
如果可能的話，優先使用“T t(u);”這種形式，而不是“T t=u;”的形式。通常，能能夠時候后者的地方，都可以使用前者，并且使用前者還有更多的好處——例如，可以帶多個參數。
在函數聲明中，如果參數是以傳值方式來傳遞的，則不要使用const。而如果在這個函數的定義中，參數是不能被修改的，那么應該使用const。
對于不是內置類型的返回值來說，當使用返回值的方式而不是返回引用的方式時，應該優先選擇返回const值。
const 和mutable都是你的朋友
優先使用新形式的類型轉換。
不要通過類型轉換去掉常量屬性，而應該使用mutable。
避免使用向下的類型轉換。
優先通過引用方式來傳遞對象參數，而不是傳值方式，并且在所有可能的地方都使用const。
避免使用內聯，除非從性能的分析上來看確實有必要這么做。
避免使用全局變量或者靜態變量。如果必須使用，那么一定要特別注意這些變量的初始化順序。
在構造函數的初始化列表中，應該把 基類按照他們在類定義中出現的先后順序進行排列。
在編寫代碼時，永遠都不應該依賴函數參數的求值順序