編程的好習慣
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
調試能否成功一方面在于方法,另外很大程度上取決于個人的經驗。但在調試時,通常應該遵循一些原則。
1、確定錯誤的性質和位置的原則 分析、思考與錯誤征兆有關的信息,避開死胡同。調試工具只是一種輔助手段。利用調試工具可以幫助思考,但不能代替思考。通常避免使用試探法,最多只能將它當作最后手段,畢竟小概率事件有時也會發生。 2、修改錯誤的原則 在出現錯誤的地方,很可能還有別的錯誤。修改錯誤的一個常見失誤是只修改了這個錯誤的征兆或這個錯誤的表現,而沒有修改錯誤本身。小心修正一個錯誤的同時又引入新的錯誤。 有效減少調試時間 1、繪制程序流程圖 一些程序員認為,繪制程序流程圖是件瑣碎的事,而且浪費時間。其實不然,當其他人對著諾大的程序一籌莫展時,面對紛紜復雜的關系理不出頭緒時,使用程序流程圖絕對可以事半功倍。因此,建議在編寫程序前先繪制程序流程圖,這樣變成的思路有條理,調試時同樣會有條不紊。若編寫程序之前沒有繪制流程圖,當排錯沒有進展時,可以馬上編寫流程圖。你會發現,程序中某些分支或細節被忽略了,這些細節可能就是程序出錯的地方。 2、不要過多依賴單步調試 尤其在調試串口程序或調試一些對時間要求比較高的程序時,數據只在一瞬間有效,可謂稍縱即逝。所以等到單步執行到那里時,數據早已更改了,當然調試也就不會得到什么有意義的結果了。 3、變量的定義 變量名一定要有意義,而且同一個程序中,同一個變量名只讓它做一件事。不要為了節省空間,一“物”多用。現在的計算機內存足夠大,多幾個變量不會對程序的性能有本質的影響。 4、程序的結構 合理地設計程序結構。在面向對象的程序設計中,將相關的功能做成一個成員函數,盡量降低各成員函數間的耦合性。其實,在過程化程序設計中,就是代碼模塊化的表現。 5、修改代碼的原則 在程序徹底正常運行前,決不要輕易刪除一段代碼,即使當時認為這段代碼肯定時錯的。現在的集成開發環境都提供了注釋工具,將暫時認為錯誤的代碼注釋掉要優于直接刪除。若同一段代碼修改多次,還應該在代碼后面注明修改的時間及修改的原因,這些信息在后續的調試中會給你帶來幫助。 6、檢查循環語句 循環語句經常是造成程序沒有任何響應的罪魁禍首。詳細檢查程序中使用的每一個循環語句,尤其是while()循環語句。 7、與外部設備打交道 程序中,當操作文件、打開串口時,一定要編寫出錯的代碼。因為這些硬件設備隨時、隨機都有可能不滿足編寫程序時的條件。 8、數組下標和循環的上下限 為簡化程序的編寫,對于大量的、有規律的數據處理,通常都會選擇采用數組和循環來實現。那么,要小心了,設置的數組下標是否滿足實際數據需要,循環的上下限是否漏掉了數據的兩個端點值。 9、屏蔽無關的代碼 當調試某個功能的代碼時,為縮小查找范圍,可以注釋掉與其無關的其他代碼,或者注釋掉該段代碼的某個分支,這樣會加快找到問題的根源。 繪制程序流程圖、變量的定義并且加相應的代碼注釋,這是一個很好的習慣。起初,開始寫些程序時,變量名隨便使用,并沒有做相應的注釋,在其他同事查看代碼時,不厭其煩的來問我,這些代碼是實現什么功能,那些代碼又是起著什么作用,而因為當時沒有做相應的注釋,加上時間過了很長后,自己看起來也費勁。所以養成好的編程習慣,這樣方便自己后來再次閱讀時候,快速讀懂,也方便他人迅速讀懂程序。 該文章在 2010/2/1 22:24:14 編輯過 |
相關文章
正在查詢... |