假設有一種編程的方法，能夠克服所有的困難和改正所有的錯誤，而且能夠避免重寫代碼，我相信我們都會使用這種方法。因為沒有一種完美的編程方法，我們能做的事情就只能是看我們周圍的程序員是如何做的，哪些是正確的，哪些是錯誤的。有一些編程的方法是我從實際工作中總結(jié)而來的，也確實感到它們能夠幫助我養(yǎng)成良好的編程習慣。其中最重要的一件事情就是記住，當你看到這些經(jīng)驗的時候，不要認為他們太簡單和基礎，覺得一種方法是不值得學習的。很多程序員認為檢查錯誤和寫程序注釋是浪費時間。而我認為，這些經(jīng)驗能夠幫助我們節(jié)省時間和精力。在實踐過程中，我了解到，我能夠更快的編寫代碼，代碼也更加的有效率。

做最壞的打算

假設你是一個超級程序員，你的代碼永遠都不會有錯誤。但是，如果你的完美的代碼沒有得到完美的數(shù)據(jù)，事情將會如何？你的代碼假設一個指針是合法的，或者它會把一個聲音文件當作一個圖片來處理？基本上來說，一段代碼不能假設任何事情。C語言又一個標準的函數(shù) assert, 它能夠用來捕獲錯誤。每次你的代碼接收到用戶數(shù)據(jù)，請注意要先確認數(shù)據(jù)是你所預想的。如果不是，使用assert并且打印消息來解釋出現(xiàn)了什么錯誤。這是很重要的，這樣你就能夠讓任何閱讀你的程序的人了解到，什么是正確的數(shù)據(jù)，什么是錯誤的。百分之九十的錯誤都是一些簡單的錯誤。所以，不要讓這種錯誤影響你的程序浪費調(diào)試人員的時間，而只需要簡單的在那些地方給出一個assert, 就能夠避免。百分之九十的時候它能夠容易的被改正。而另外百分之十的時候，它能夠在變成一個大的錯誤之前被調(diào)試人員注意到并且改正。不論你采用哪種編程語言，你編寫的第一個程序一般都是打印一條消息。把這個打印消息的功能作為你的程序中一個基本的函數(shù)，能夠簡單的打印任何錯誤。這樣，程序就能分辨不明顯的錯誤，你也能在任何錯誤可能出現(xiàn)的地方使用這個打印錯誤消息的函數(shù)。這樣，就能夠節(jié)省尋找錯誤的時間，從而讓改正錯誤的時間減短。

注釋

不要企圖記住你的代碼是用來做什么的。在你編寫完一段程序幾個月之后，你不會記得在編寫程序的時候的想法，也不會記得什么代碼是用來干什么的。所以，寫注釋是一個好的方法，特別是當你需要別人來閱讀你的代碼，或者是為了你半年之后還能記起來這段代碼的目的。如果有一個同事告訴你，你的代碼有一個錯誤，你將不得不重新檢查并且改正它。如果你能夠通過注釋來回憶起什么代碼用來做什么，你就能快一點找到并且改正錯誤。這個方法也是比較簡單的，只需要注明你的那一段代碼是做什么的，這就夠了。而如果你不這么做，其他的閱讀你的程序的人將看不懂它的意思，不知道變量是用來做什么的，哪些復雜的計算又是用來做什么的。如果你說明了它們的意義，就簡單多了。比如，看這樣的代碼if "(frmp>10)", "(plist.bdown & x03)", "(plist.y > pond.y)"就比看注釋要復雜的多。當你寫注釋的時候，你會得到兩種好處。

任何人都能明白你希望一段代碼去做什么，而且，如果這段代碼有錯誤，閱讀代碼的人就能發(fā)現(xiàn)，它沒有執(zhí)行你在注釋中希望它去做的事情，那樣就能盡快的發(fā)現(xiàn)錯誤和改正它。注釋是程序員最重要的工具之一。而且所有的語言都支持注釋。所以，記住，要寫注釋。

文檔

當我在寫一個文檔的時候，我記得我花了很多篇幅來寫一段關于系統(tǒng)和模塊的文檔。這個文檔是正確的，但是卻是沒有用的。因為，沒有人讀過它。很多人都忘記了還有這篇文檔，而是在需要的時候來問我，讓我來解釋給他們。

這種方法也不錯，它比查閱整個文檔快多了。很少有機會有人會花上一大段時間來通讀整個文檔。所以說，我當時寫文檔的時間是浪費了。而且，如果這個系統(tǒng)和模塊要做什么改動的話，我還必須相應的修改文檔。也就是說，這文檔讓我的勞動加倍了。但是，這并不是說文檔是不重要的。相反，如果用源代碼和說明來記錄文檔，就簡單多了。在每一個函數(shù)的開頭，都用一段注釋來解釋函數(shù)的功能，如何使用，需要注意的問題等等。如果是一段比較復雜的代碼，需要解釋你所采用的方法。沒有必要采用另外一個文件來記錄文檔，而只用在源代碼中間來寫文檔。這樣你就能夠在你需要文檔的時候隨時找到它們。其他的程序員也會很方便的使用你的代碼。而且，不象一個專門的獨立的文檔那樣，其他的程序員將會無意識的閱讀你的文檔，而不會置之不理。如果有人來問你關于某一段代碼的意思的時候，你就會明白，那一段代碼缺少明白的注釋。所以，你可以盡快的補上它，而不會有另外一個程序員來問你同樣的問題。

采用工具

在編程的工作中，你也許會常常遇到這樣一些繁重的體力勞動，比如，編譯一個程序，然后就是等待。或者你使用了別人寫的API函數(shù)，而記住這些函數(shù)的名稱和參數(shù)是一個很累的活兒。這些工作并沒有什么技術(shù)可言，比如說編譯程序，每天晚上都會有人把新增加的程序放到庫里，然后第二天上班以后你需要來重新編譯它們，往往都是一些重復的工作，但是由于程序很大，編譯的過程很漫長，而你就要陷入等待狀態(tài)。那么，為什么不采用工具呢？或者寫一些這樣的工具？我就這樣做過。我寫過一個程序，讓它每天早上3點開始，重新編譯程序，到了早上8點左右，差不多就編譯完成了。然后捕獲錯誤，如果有的話，就發(fā)電子郵件給相關的人。這樣，到了上班的時間，每個人都能得到一個最新的，編譯好的程序。如果代碼中有錯誤，還能最快的得到錯誤報告。再比如，我需要使用別人寫的API函數(shù)，當然，我不能指望每個人寫的函數(shù)都采用同樣的命名方法和參數(shù)定義方法，也不可能每次需要使用的時候都去查看文檔，那樣太浪費時間而且效率太低。我寫了一個工具，讓它來檢查我的函數(shù)調(diào)用是否正確，參數(shù)是否正確。如果有錯誤，則從文檔中找到可能的函數(shù)，并在錯誤日志中給予提示。然后我就能很快的編寫代碼，而不用擔心函數(shù)拼寫，參數(shù)調(diào)用的類型和順序了。你也可以這么做，當下次有人來問你某個函數(shù)的名稱，參數(shù)類型，參數(shù)順序的時候，你就能夠告訴他，該怎么做，用什么工具了。

可復用的代碼

有一個好的比方，用來描述一個引擎。有一個不是程序員的朋友問過我一個問題，什么是程序引擎？有什么作用？為什么要用引擎？我盡量的用通俗的語言回答它，一個程序引擎就像一個汽車的引擎。沒有它，汽車不能啟動，但是，同時，一個沒有輪胎的引擎，也是沒有用處的。

我想，這是一個好的例子。這個朋友說，當你的引擎不能用的時候，你可以換一個。如果傳動帶壞了，你可以換一個新的，同時把引擎的性能調(diào)整到最好。同樣，一個引擎有相同的部分，比如，傳動裝置，等等。它們對于一個引擎是重要的，如果某一個部分壞了，你不能不拆開引擎來更換它。

然后我的朋友總結(jié)道：如果你從頭來寫一個程序引擎，你就不得不從頭來寫所有的傳動帶，所有的零件。如果你能用一些以前用過的部分，你就能簡單的把它們拼裝到一起而不用重新寫了。

沒錯。他并不懂得如何去寫程序，但是他道出了編程的真諦。這也是一個普通的程序員和一個高級程序員的區(qū)別。采用可復用的代碼，讓工作變得簡單。

寫通用的代碼的關鍵是，不要讓你的子程序變長，不要超過一屏。關鍵要把你要做的事情分解開，變成小巧的，可以復用的函數(shù)，要么完成一個功能，要么調(diào)用另外的函數(shù)來完成一個完整的功能。

比如，VectorAdd()可能包含了一段代碼把兩個vectors的元素合并到一起，而SceneDisplay可能包含了調(diào)用PrepRender(), Render2dObjects(), Rende rHud()的代碼。每一個函數(shù)可能都只有幾行。

當你把代碼分解成小的部分的時候，你將能夠集中注意力到一些在其他地方可以復用的功能上。在前一個例子中，RenderHud()和RenderDebugText()可能共享了同樣的一段函數(shù)調(diào)用，因為它們都是在屏幕上描畫一些對象。

作者：ariesram Email:  ariesram@linuxaid.com.cn 或 ariesram@may10.ca