養成“好”的編程習慣

2019-11-17 04:40:20

字體：大中小

來源：轉載

供稿：網友

假設有一種編程的方法，能夠克服所有的困難和改正所有的錯誤，而且能夠避免重寫代碼，我相信我們都會使用這種方法。

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

　　做最壞的打算

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

　　注釋

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

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

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

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

　　采用工具

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

上一篇：協議型網絡游戲外掛制作之外掛窗口

下一篇：探討軟件工程概念模型