1. 動手編碼之前，你需要對要編碼實現的解決方案有乙個正式的或粗略的設計。永遠不要在沒有任何設計的前提下就開始編碼，除非所編**不重要。
2. 優秀的**文件跟程式語言知識一樣重要。在**原始檔中，為每個主要的**段新增注釋，解釋**的基本邏輯。最好註明程式的構建和修改日期，以及修改的原因也是非常有必要的。
3. 維護程式的各個版本同樣重要。當前有些程式設計工具都自帶乙個版本管理工具。無論你什麼時候改變自己的程式，它們都會將其儲存為.bak檔案。
我的方法是為每個程式維護三個不同的版本。比如說，我有乙個名為program.c的檔案，這個檔案同時也被其他專案組成員使用。我把這個檔案複製為
program.c.old作為備份檔案，並且當我修改時，我會備份另乙個名為program.c.wrk的副本檔案。當成功完成修改時替換
program.c.wrk檔案。
你還可以給自己的程式版本新增乙個日期或一些注釋，像program260505.c或programreadfnwrking.c。
4. 如果工程包含多個原始檔，則聲稱乙個readme檔案，註明每個原始檔、資料檔案、臨時檔案以及日誌檔案(如果有的話)的作用。你還可以註明編譯和執行步驟。
5. 有時候，你一定想知道為什麼if語句沒有得到預想的結果。可能你使用的是等號，也就是「=」，而不是條件判定符號「==」。乙個比較好的辦法是用相反的順序寫條件語句。因此，你的條件語句應該如下：
if(10==i)…因此，如果你錯誤地寫成了單個等於號，在編譯的時候也能檢查出來並報錯。
6.使用迴圈和條件語句時，先把左右括號對應起來，然後再在裡面寫其他語句。也就是：
**:1for(int i=0;i<10;i++)2
注：每一行開頭的數字表明寫迴圈**的順序。
7. 避免使用幻數（magic numbers）。例如，不要寫
**: circlearea = 3.14 * pow(radius,2);
而要使用如下**：
**: #define pi 3.14
circlearea = pi * pow(radius,2);
8. 使用有意義的變數和函式名稱。例如，使用『radius』來代替圓的半徑，而不是用『r』來表示。同樣，函式名『calculatearea』要比其他任
何隱晦的縮寫要好得多。匆忙之下，我們也許會使用縮寫的變數名，但一開始節省時間的話，之後會浪費更多的時間，去猜測縮寫變數名代表什麼。（編註：）
9. 為後面的除錯使用列印語句，這是個好習慣。但是，當完成最後**後，去掉這些語句，有時也是一項危險的任務。新增乙個方法，用於輸出除錯資訊。當最終版本生成時，只要把這個方法注釋掉就行。因此，只在乙個地方做修改就可以了。
10. **編寫完之後，開始優化**。之前宣告的一些變數，現在可能沒用了。同樣，並不依賴迴圈的一些宣告可以移到迴圈模組之外去。紮實的編譯知識同樣會對以後的**優化有所幫助。
11. 對自己的作業系統和硬體要有足夠的了解，你可以從資源占用等方面提公升程式的效能。
12. 編寫**時要合理使用縮排，以使**清晰可讀。
13. 把專案檔案放到source、headers、make、exes等不同的資料夾中。
14. 研究別人編寫的**。這可以讓你學習到新的程式設計技術，以及他們解決和你相同的任務時所使用的方法。
15. 最後一條（但不是最不重要的一條)，備份源**檔案，這樣當硬碟出錯或相同的問題發生時，不至於前功盡棄。
附加：補充一條，堅持使用一種命名模式。如果你打算用匈牙利命名法，那就堅持並廣泛使用，否則將適得其反。參見微軟資深工程師 eric lippert 的這篇文章《閱讀**不簡單》。
編者後話
15個程式設計好習慣
編者按 這是國外程式設計師al katib總結的一些程式設計習慣。1.動手編碼之前，你需要對要編碼實現的解決方案有乙個正式的或粗略的設計。永遠不要在沒有任何設計的前提下就開始編碼，除非所編 不重要。2.優秀的 文件跟程式語言知識一樣重要。在 原始檔中，為每個主要的 段新增注釋，解釋 的基本邏輯。最好...
15個程式設計好習慣
這是國外程式設計師al katib總結的一些程式設計習慣。1.動手編碼之前，你需要對要編碼實現的解決方案有乙個正式的或粗略的設計。永遠不要在沒有任何設計的前提下就開始編碼，除非所編 不重要。2.優秀的 文件跟程式語言知識一樣重要。在 原始檔中，為每個主要的 段新增注釋，解釋 的基本邏輯。最好註明程式...
程式設計好習慣
我們在編碼的時候總是希望能寫出風格良好，清晰 健壯的程式，把 當成一件藝術品來看待 來雕琢，讓 coding成為一種藝術。看了很多大牛關於程式設計風格與修養方面的文章，很受啟發，結合自己體會，簡錄幾條，提醒自己時刻注意。1.引數檢查 對於有引數的函式，首先要對引數的合法性進行檢查。可以利用asser...