修練8年C 物件導向程式設計之體會

2 良好的程式設計風格

內功深厚的武林高手出招往往平淡無奇。同理，程式設計高手也不會用奇門怪招寫程式。良好的程式設計風格是產生高質量程式的前提。

2.1 命名約定

有不少人程式設計時用拼音給函式或變數命名，這樣做並不能說明你很愛國，卻會讓用此程式的人迷糊（很多南方人不懂拼音，我就不懂）。程式中的英文一般不會太複雜，用詞要力求準確。匈牙利命名法是microsoft 公司倡導的[maguire 1993]，雖然很煩瑣，但用習慣了也就成了自然。沒有人強迫你採用何種命名法，但有一點應該做到：自己的程式命名必須一致。

以下是我程式設計時採用的命名約定：

（1）巨集定義用大寫字母加下劃線表示，如max_length；

（2）函式用大寫字母開頭的單詞組合而成，如setname, getname ；

（3）指標變數加字首p，如*pnode ；

（4）bool 變數加字首b，如bflag ；

（5）int 變數加字首i，如iwidth ；

（6）float 變數加字首f，如fwidth ；

（7）double 變數加字首d，如dwidth ；

（8）字串變數加字首str，如strname ；

（9）列舉變數加字首e，如edrawmode ；

（10）類的成員變數加字首m_，如m_strname, m_iwidth ；

對於int, float, double 型的變數，如果變數名的含義十分明顯，則不加字首，避免煩瑣。如用於迴圈的int 型變數i,j,k ；float 型的三維座標（x,y,z）等。

2.2 使用斷言

程式一般分為debug 版本和release 版本，debug 版本用於內部除錯，release 版本發行給使用者使用。斷言assert 是僅在debug 版本起作用的巨集，它用於檢查「不應該」發生的情況。以下是乙個記憶體複製程式，在執行過程中，如果assert 的引數為假，那麼程式就會中止（一般地還會出現提示對話，說明在什麼地方引發了assert）。

//複製不重疊的記憶體塊

void memcpy(void *pvto, void *pvfrom, size_t size)

assert 不是乙個倉促拼湊起來的巨集，為了不在程式的debug 版本和release 版本引起差別，assert 不應該產生任何***。所以assert 不是函式，而是巨集。程式設計師可以把assert 看成乙個在任何系統狀態下都可以安全使用的無害測試手段。

很少有比跟蹤到程式的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時間，不是為了排除錯誤，而只是為了弄清楚這個錯誤到底是什麼。有的時候，程式設計師偶爾還會設計出有錯誤的斷言。所以如果搞不清楚斷言檢查的是什麼，就很難判斷錯誤是出現在程式中，還是出現在斷言中。幸運的是這個問題很好解決，只要加上清晰的注釋即可。這本是顯而易見的事情，可是很少有程式設計師這樣做。這好比乙個人在森林裡，看到樹上釘著一塊「危險」的大牌子。但危險到底是什麼？樹要倒？有廢井？有野獸？除非告訴人們「危險」是什麼，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程式設計師忽略，甚至被刪除。[maguire 1993]

以下是使用斷言的幾個原則：

（1）使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，後者是必然存在的並且是一定要作出處理的。

（2）使用斷言對函式的引數進行確認。

（3）在編寫函式時，要進行反覆的考查，並且自問：「我打算做哪些假定？」一旦確定了的

假定，就要使用斷言對假定進行檢查。

（4）一般教科書都鼓勵程式設計師們進行防錯性的程式設計，但要記住這種程式設計風格會隱瞞錯誤。當進行防錯性程式設計時，如果「不可能發生」的事情的確發生了，則要使用斷言進行報警。

修練8年C 物件導向程式設計之體會

修練8年C 物件導向程式設計之體會

修練8年C 物件導向程式設計之體會

修練8年C 物件導向程式設計之體會2

相關推薦