很少有比跟蹤到程序的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時間，不是爲了排除錯誤，而只是爲了弄清楚這個錯誤到底是什麼。有的時候，程序員偶爾還會設計出有錯誤的斷言。所以如果搞不清楚斷言檢查的是什麼，就很難判斷錯誤是出現在程序中，還是出現在斷言中。幸運的是這個問題很好解決，只要加上清晰的註釋即可。這本是顯而易見的事情，可是很少有程序員這樣做。這好比一個人在森林裏，看到樹上釘着一塊“危險”的大牌子。但危險到底是什麼？樹要倒？有廢井？有野獸？除非告訴人們“危險”是什麼，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程序員忽略，甚至被刪除。
【規則6-5-1】使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，後者是必然存在的並且是一定要作出處理的。
【規則6-5-2】在函數的入口處，使用斷言檢查參數的有效性（合法性）。
【建議6-5-1】在編寫函數時，要進行反覆的考查，並且自問：“我打算做哪些假定？”一旦確定了的假定，就要使用斷言對假定進行檢查。
【建議6-5-2】一般教科書都鼓勵程序員們進行防錯設計，但要記住這種編程風格可能會隱瞞錯誤。當進行防錯設計時，如果“不可能發生”的事情的確發生了，則要使用斷言進行報警。
ASSERT宏中應該包含的元素：
判斷條件；輸出當前斷言失敗的位置（文件、行數等）；返回錯誤；終止程序...
幾種典型的ASSERT的寫法：
VC中的寫法：
#define ASSERT(f) \
do \
{ \
if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \
AfxDebugBreak(); \
} while (0) \
#define _ASSERT(expr) \
do { if (!(expr) && \
(1 == _CrtDbgReport(_CRT_ASSERT, __FILE__, __LINE__, NULL, NULL))) \
_CrtDbgBreak(); } while (0)
其他平臺的寫法：
# define ASSERT(x) ((x) || (dbg_printf("assertion failed ("__FILE__":%d): \"%s\"\n",__LINE__,#x), break_point(), FALSE))