除錯能否成功一方面在於方法，另外很大程度上取決於個人的經驗。但是在除錯的時候，通常要遵循以下一些原則：
1、確定錯誤的性質和位置
分析、思考與錯誤徵兆有關的資訊，避開死胡同。除錯工具只是一種輔助手段，充分利用vc自帶的除錯工具可以幫助思考，但不能代替思考。通常避免使用 試探法，最多只能將它當作最後的手段。畢竟小概率事件有時也會發生。
2、 修改錯誤的原則
在出現錯誤的地方，很有可能還有別的錯誤。修改錯誤的乙個常見失誤是只修改了這個錯誤的徵兆或這個錯誤的表現，而沒有找到源頭修改錯誤本身。小心修 正乙個錯誤的同時又引入新的錯誤。
3、繪製程式流程圖
很多人都認為這個是件繁瑣的事，而且浪費時間。其實不然，當你讀要乙個諾大的程式一籌莫展時，面對紛紛複雜的關係理不出頭緒時，使用流程圖絕對可以 事半功倍。
4、不要過多的依賴f10
除錯串列埠程式與除錯其他程式（如資料庫）不一樣，串列埠程式對時間很敏感。串列埠上的資料只在一瞬間有效，可謂稍縱即逝。所以等到地f10單步執行到那 裡時，串列埠上的資料早已更改了，當然除錯也不會得到什麼有意義的結果。
5、變數的定義
變數名一定要有意義，而且在同乙個程式中，同乙個變數只讓他做一件事。不要為了節省空間，一物多用。現在的計算機可以說記憶體是足夠大，多幾個變數不 會對程式的效能有本質的影響。但是變數也不要隨手寫，我看到這份**中，常常有精確到byte，所以這裡一定要規範，不然，到最後你往裡面扔了一大堆 udp包，結果自己都會結舌。
6、程式的結構
合理地設計程式結構。在物件導向的程式設計中，將相關的功能做成乙個成員函式，盡量降低各成員函式間的耦合性。其實，在過程化程式設計中，就是** 模組化的表現。這份**由演算法設計、介面模組、通訊模組、錯誤處理模組等等都是相當的完美，所以我是發自心底的佩服。
7、修改**的原則
在程式徹底正常執行前，絕對不要輕易地刪除一段**，即使你當時認為這段**肯定是錯的或無用的。現在的整合開發環境比如vc都提供了良好的注釋工 具，將暫時認為錯誤的**注釋掉要優於直接刪除。若同一段**修改多次，還應該在**後面註明修改的時候、原因等，這些資訊將在後續的除錯與維護中，會給 你帶來莫大的幫助。
8、檢查迴圈語句
迴圈語句經常是造成程式沒有任何相依的罪魁禍首。詳細檢查程式中使用的每乙個迴圈語句，尤其是while()迴圈語句。
9、與外部裝置打交道
程式中，當操作檔案、開啟串列埠時，一定要編寫出錯處理的**。因為這些硬體裝置隨時、隨機都有可能不滿足編寫程式時的條件。
10、陣列與迴圈的上下限
為了簡化**，對於大量的、有規律的資料處理，通常都會採用陣列或迴圈來實現。那麼，你一定要小心了，設定的陣列下標是否能滿足實際資料需要，迴圈 的上下限是否漏掉資料的那兩個起始值。
11、無效控制代碼或指標
這種問題相信大多朋友都會常常遇到，也許編譯連線都沒有問題，但執行句出現了致命的bug、什麼xxo記憶體不能read等等，其實都是一樣 「形象」的問題，所以這時候請你多寫些assert()或其他seh處理**。
12、遮蔽無關的**
當除錯某個功能的**時，為了縮小查詢範圍，完全可以注釋掉與其無關的其他**，或者注釋掉該**的某個分支，這樣會加快找到問題的確根源。
串列埠程式除錯總結
除錯能否成功一方面在於方法，另外很大程度上取決於個人的經驗。但是在除錯的時候，通常要遵循以下一些原則 1 確定錯誤的性質和位置 分析 思考與錯誤徵兆有關的資訊，避開死胡同。除錯工具只是一種輔助手段，充分利用vc自帶的除錯工具可以幫助思考，但不能代替思考。通常避免使用 試探法，最多只能將它當作最後的手...
高速串列埠除錯總結
高速串列埠除錯總結 最近有個模組專案使用的是 qualcomm 6290 的bb,該晶元的 main uart 口支援高達 4mbps 的速率.由於一般 pc上的超級中端等最高僅支援 921600 的速率,因此給該 uart 口測試產生了一些難度 下面就簡要描述一下測試的過程.我們的測試想法是先讓模...
串列埠通訊除錯總結
1.除錯目標 mcu通過串列埠發資料到模組中，中間通過乙個232晶元，再通過乙個插座，最後轉接到模組中 模組中是乙個232晶元 控制晶元 結構順序 板子mcu 232晶元 插座 模組中 232晶元 2.除錯步驟 1 剛剛開始除錯的時候，思想很混亂，不知道從 開始除錯，先把 寫完，其實也不知道寫的什麼...