這個主題和程式碼的實際寫作有關，而且內容和用法相互交織，以下只是對於其內容的一個劃分。《程式設計珠璣》上只用了兩個章節20頁左右的篇幅介紹，如果希望能獲得更多的例項和技巧，我比較推崇《程式設計實踐》 (Practise of Programming)、《程式設計精粹：編寫高質量C語言程式碼》(Writing Solid Code)這兩本書，只要有一般的C語言基礎就能讀懂，而且讀起來比較快，讀完後能提高不少coding的實踐水平。

　　　　目錄

 迴圈不變式（invariant）

　　迴圈不變式主要用來幫助理解演算法的正確性，具體來看，比較針對於迴圈迭代。形式上很類似與數學歸納法，它是一個需要保證正確斷言。對於迴圈不變式，必須證明它的三個性質：

初始化：它在迴圈的第一輪迭代開始之前，應該是正確的。

保持：如果在迴圈的某一次迭代開始之前它是正確的，那麼，在下一次迭代開始之前，它也應該保持正確。

終止：迴圈能夠終止，並且可以得到期望的結果。

debug之腳手架

　　聽起來挺玄乎，其實所謂的腳手架，就是在debug版本里加入的為了驗證程式是否正確的額外程式碼，比如一條為了確定迴圈中臨時變數是否按期望變化的printf語句，這比複雜的偵錯程式更快。我相信很多人在寫程式碼時都這樣做過，看到這裡，我們並不需要為自己過去“簡陋”的除錯方式而不安，而是繼續合理地使用它。

　　腳手架能完成更多的工作，不僅限於變數追蹤。利用斷言，可以建立腳手架進行程式的自動測試而不是人為的追蹤，也可以利用clock()建立腳手架，把待測的程式碼放在兩個clock()中間測試執行時間（相比之下，我更喜歡用gettimeofday()）。以上三種腳手架的用法是《程式設計珠璣》提到的例子，關於這種程式碼可以做更多的引申，以下內容結合了Practise of Programming和Writing Solid Code的相關內容。

1.#ifdef DEBUG

　　很多人都使用過下面這樣的程式碼：

#ifdef DEBUG
    ...
#endif

　　這種想法是同時維護除錯和非除錯（即交付）兩個版本，在除錯版本中自動地查錯；最後提交交付版本。當然，這種方法的關鍵是保證除錯程式碼不在最終產品中出現。只是這種程式碼在原來的程式碼裡看起來十分突兀（排版不好看，而且可能看上去喧賓奪主），使用斷言assert()是一個代替方案之一，它只在定義了DEBUG時才有效，在我的Ubuntu的assert.h裡是如果定義了NDEBUG就無效。關於斷言會在後面詳寫，這裡點到為止。

2.外殼函式/包裹函式

　　做法是把待測試或者可能發生錯誤而需要檢測的函式用一段程式碼加一個外殼，或者說是包裹起來，在其中增加出錯檢查和處理程式碼，並提供合理的返回值。這兩種名稱前者出自《程式設計實踐》，後者見於UNP，舉一個UNP上的簡單的例子：

int Socket(int family, int type, int protocol)
{
    int n;
    if( (n = socket(family,type,protocol)) < 0)
        err_sys("socket error");
    return n;
}

3.用不同的演算法驗證正確性

 　　如果編寫了一個較快的演算法又擔心其不正確，想要檢查其正確性怎麼辦？在腳手架中構造一個包括能提供同樣功能並且正確但速度較慢的演算法（往往是舊版本中所留下的），比較兩者的執行結果。

4.提高程式碼覆蓋度

在if判斷中，總有一部分程式碼未必執行。如果想要測試不常執行的程式碼的正確性，可以用腳手架強制執行這部分程式碼。

5.消除隨機性，使錯誤重現

利用腳手架對分配的記憶體塊用garbage值0xA3而不是0填充，這樣當發現指標指向0xA3A3或內容是連續的0xA3A3時，顯然是個未定義的值，需要排錯。具體的取值和系統有關，0xA3是早期macintosh的建議用的garbage值。

6.不要擔心腳手架帶來的效能損失

正如Writing Solid Code所言，不要把對交付版本的約束應用到相應的除錯版本上，要用大小和速度來換取錯誤檢查能力。腳手架只是為了查錯，在交付版本中它們是不存在的。

斷言（assert）

 　　正如在腳手架中提到的，斷言可以對程式正確性的測試。除此以外，在一段小型的程式碼demo中，編寫斷言遠比精心編制一套完整的出錯處理機制或者繁複的#ifdef DEBUG要簡單的多。

　　為了幫助理解這個巨集，Writing Solid Code探討了assert巨集的一種實現機制：

#ifdef DEBUG
    void _Assert(char*, unsigend);
#define ASSERT(f)    \
    if(f)                        \
        NULL;                \
    else
        _Assert(__FILE__,__LINE__)
#else
    #define ASSERT(f)    NULL
#endif

　　而真正的處理函式是

void _Assert(char* strFile, unsigned uLine)
{
    fflush(stdout);
    fprintf(stderr,"\nAssertion failed:%s, line %u\n",strFile,uLine);
    fflush(stderr);
    abort();
}

為什麼要用巨集定義+函式實現，並將巨集中的__LINE__傳遞給後面實現的函式而不是僅僅靠巨集本身實現？因為__LINE__用其所在的行號替換內容，使用函式則只會變成該函式內部的行號，而使用巨集則只是把__LINE__放到對應需要檢查的位置。更具體的說明可以參考以下連結：

　　另外，這個斷言巨集可以作為《程式設計珠璣（續）》習題3.5的完善解答。

往期回顧：