假設(shè)有一種編程的方法,能夠克服所有的困難和改正所有的錯誤,而且能夠避免重寫代碼,我相信我們都會使用這種方法。因為沒有一種完美的編程方法,我們能做的事情就只能是看我們周圍的程序員是如何做的,哪些是正確的,哪些是錯誤的。有一些編程的方法是我從實際工作中總結(jié)而來的,也確實感到它們能夠幫助我養(yǎng)成良好的編程習(xí)慣。其中最重要的一件事情就是記住,當(dāng)你看到這些經(jīng)驗的時候,不要認(rèn)為他們太簡單和基礎(chǔ),覺得一種方法是不值得學(xué)習(xí)的。很多程序員認(rèn)為檢查錯誤和寫程序注釋是浪費時間。而我認(rèn)為,這些經(jīng)驗?zāi)軌驇椭覀児?jié)省時間和精力。在實踐過程中,我了解到,我能夠更快的編寫代碼,代碼也更加的有效率。
做最壞的打算
假設(shè)你是一個超級程序員,你的代碼永遠(yuǎn)都不會有錯誤。但是,如果你的完美的代碼沒有得到完美的數(shù)據(jù),事情將會如何?你的代碼假設(shè)一個指針是合法的,或者它會把一個聲音文件當(dāng)作一個圖片來處理?基本上來說,一段代碼不能假設(shè)任何事情。C語言又一個標(biāo)準(zhǔn)的函數(shù) assert, 它能夠用來捕獲錯誤。每次你的代碼接收到用戶數(shù)據(jù),請注意要先確認(rèn)數(shù)據(jù)是你所預(yù)想的。如果不是,使用assert并且打印消息來解釋出現(xiàn)了什么錯誤。這是很重要的,這樣你就能夠讓任何閱讀你的程序的人了解到,什么是正確的數(shù)據(jù),什么是錯誤的。百分之九十的錯誤都是一些簡單的錯誤。所以,不要讓這種錯誤影響你的程序浪費調(diào)試人員的時間,而只需要簡單的在那些地方給出一個assert, 就能夠避免。百分之九十的時候它能夠容易的被改正。而另外百分之十的時候,它能夠在變成一個大的錯誤之前被調(diào)試人員注意到并且改正。不論你采用哪種編程語言,你編寫的第一個程序一般都是打印一條消息。把這個打印消息的功能作為你的程序中一個基本的函數(shù),能夠簡單的打印任何錯誤。這樣,程序就能分辨不明顯的錯誤,你也能在任何錯誤可能出現(xiàn)的地方使用這個打印錯誤消息的函數(shù)。這樣,就能夠節(jié)省尋找錯誤的時間,從而讓改正錯誤的時間減短。
注釋
不要企圖記住你的代碼是用來做什么的。在你編寫完一段程序幾個月之后,你不會記得在編寫程序的時候的想法,也不會記得什么代碼是用來干什么的。所以,寫注釋是一個好的方法,特別是當(dāng)你需要別人來閱讀你的代碼,或者是為了你半年之后還能記起來這段代碼的目的。如果有一個同事告訴你,你的代碼有一個錯誤,你將不得不重新檢查并且改正它。如果你能夠通過注釋來回憶起什么代碼用來做什么,你就能快一點找到并且改正錯誤。這個方法也是比較簡單的,只需要注明你的那一段代碼是做什么的,這就夠了。而如果你不這么做,其他的閱讀你的程序的人將看不懂它的意思,不知道變量是用來做什么的,哪些復(fù)雜的計算又是用來做什么的。如果你說明了它們的意義,就簡單多了。比如,看這樣的代碼if "(frmp>10)", "(plist.bdown & x03)", "(plist.y > pond.y)"就比看注釋要復(fù)雜的多。當(dāng)你寫注釋的時候,你會得到兩種好處。
任何人都能明白你希望一段代碼去做什么,而且,如果這段代碼有錯誤,閱讀代碼的人就能發(fā)現(xiàn),它沒有執(zhí)行你在注釋中希望它去做的事情,那樣就能盡快的發(fā)現(xiàn)錯誤和改正它。注釋是程序員最重要的工具之一。而且所有的語言都支持注釋。所以,記住,要寫注釋。
文檔
當(dāng)我在寫一個文檔的時候,我記得我花了很多篇幅來寫一段關(guān)于系統(tǒng)和模塊的文檔。這個文檔是正確的,但是卻是沒有用的。因為,沒有人讀過它。很多人都忘記了還有這篇文檔,而是在需要的時候來問我,讓我來解釋給他們。
這種方法也不錯,它比查閱整個文檔快多了。很少有機會有人會花上一大段時間來通讀整個文檔。所以說,我當(dāng)時寫文檔的時間是浪費了。而且,如果這個系統(tǒng)和模塊要做什么改動的話,我還必須相應(yīng)的修改文檔。也就是說,這文檔讓我的勞動加倍了。但是,這并不是說文檔是不重要的。相反,如果用源代碼和說明來記錄文檔,就簡單多了。在每一個函數(shù)的開頭,都用一段注釋來解釋函數(shù)的功能,如何使用,需要注意的問題等等。如果是一段比較復(fù)雜的代碼,需要解釋你所采用的方法。沒有必要采用另外一個文件來記錄文檔,而只用在源代碼中間來寫文檔。這樣你就能夠在你需要文檔的時候隨時找到它們。其他的程序員也會很方便的使用你的代碼。而且,不象一個專門的獨立的文檔那樣,其他的程序員將會無意識的閱讀你的文檔,而不會置之不理。如果有人來問你關(guān)于某一段代碼的意思的時候,你就會明白,那一段代碼缺少明白的注釋。所以,你可以盡快的補上它,而不會有另外一個程序員來問你同樣的問題。
采用工具
在編程的工作中,你也許會常常遇到這樣一些繁重的體力勞動,比如,編譯一個程序,然后就是等待?;蛘吣闶褂昧藙e人寫的API函數(shù),而記住這些函數(shù)的名稱和參數(shù)是一個很累的活兒。這些工作并沒有什么技術(shù)可言,比如說編譯程序,每天晚上都會有人把新增加的程序放到庫里,然后第二天上班以后你需要來重新編譯它們,往往都是一些重復(fù)的工作,但是由于程序很大,編譯的過程很漫長,而你就要陷入等待狀態(tài)。那么,為什么不采用工具呢?或者寫一些這樣的工具?我就這樣做過。我寫過一個程序,讓它每天早上3點開始,重新編譯程序,到了早上8點左右,差不多就編譯完成了。然后捕獲錯誤,如果有的話,就發(fā)電子郵件給相關(guān)的人。這樣,到了上班的時間,每個人都能得到一個最新的,編譯好的程序。如果代碼中有錯誤,還能最快的得到錯誤報告。再比如,我需要使用別人寫的API函數(shù),當(dāng)然,我不能指望每個人寫的函數(shù)都采用同樣的命名方法和參數(shù)定義方法,也不可能每次需要使用的時候都去查看文檔,那樣太浪費時間而且效率太低。我寫了一個工具,讓它來檢查我的函數(shù)調(diào)用是否正確,參數(shù)是否正確。如果有錯誤,則從文檔中找到可能的函數(shù),并在錯誤日志中給予提示。然后我就能很快的編寫代碼,而不用擔(dān)心函數(shù)拼寫,參數(shù)調(diào)用的類型和順序了。你也可以這么做,當(dāng)下次有人來問你某個函數(shù)的名稱,參數(shù)類型,參數(shù)順序的時候,你就能夠告訴他,該怎么做,用什么工具了。
可復(fù)用的代碼
有一個好的比方,用來描述一個引擎。有一個不是程序員的朋友問過我一個問題,什么是程序引擎?有什么作用?為什么要用引擎?我盡量的用通俗的語言回答它,一個程序引擎就像一個汽車的引擎。沒有它,汽車不能啟動,但是,同時,一個沒有輪胎的引擎,也是沒有用處的。
我想,這是一個好的例子。這個朋友說,當(dāng)你的引擎不能用的時候,你可以換一個。如果傳動帶壞了,你可以換一個新的,同時把引擎的性能調(diào)整到最好。同樣,一個引擎有相同的部分,比如,傳動裝置,等等。它們對于一個引擎是重要的,如果某一個部分壞了,你不能不拆開引擎來更換它。
然后我的朋友總結(jié)道:如果你從頭來寫一個程序引擎,你就不得不從頭來寫所有的傳動帶,所有的零件。如果你能用一些以前用過的部分,你就能簡單的把它們拼裝到一起而不用重新寫了。
沒錯。他并不懂得如何去寫程序,但是他道出了編程的真諦。這也是一個普通的程序員和一個高級程序員的區(qū)別。采用可復(fù)用的代碼,讓工作變得簡單。
寫通用的代碼的關(guān)鍵是,不要讓你的子程序變長,不要超過一屏。關(guān)鍵要把你要做的事情分解開,變成小巧的,可以復(fù)用的函數(shù),要么完成一個功能,要么調(diào)用另外的函數(shù)來完成一個完整的功能。
比如,VectorAdd()可能包含了一段代碼把兩個vectors的元素合并到一起,而SceneDisplay可能包含了調(diào)用PrepRender(), Render2dObjects(), Rende rHud()的代碼。每一個函數(shù)可能都只有幾行。
當(dāng)你把代碼分解成小的部分的時候,你將能夠集中注意力到一些在其他地方可以復(fù)用的功能上。在前一個例子中,RenderHud()和RenderDebugText()可能共享了同樣的一段函數(shù)調(diào)用,因為它們都是在屏幕上描畫一些對象。
作者:ariesram Email: ariesram@linuxaid.com.cn 或 ariesram@may10.ca